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Abstract 

In  the  60's  the  United  Status  and  the  Union  of  Soviet  Socialist  Republics  engaged  in  a 
"space  race"  to  be  the  first  to  put  a  man  on  the  moon.  Today,  the  space  race  is  between 
large  multinational  telecommunication  corporations  with  the  winner  receiving  the 
financial  rewards  by  providing  communication  services  to  the  billions  without  even  a 
simple  telephone.  Many  entrants  are  using  Low  Earth  Orbit  (LEO)  satellites  to  provide 
the  communications  infrastructure,  but  the  number  of  customers  a  satellite  can  support  is 
limited  by  bandwidth  available.  This  resource  must  be  used  efficiently,  and  this  involves 
reducing  the  management  overhead.  This  thesis  investigates  one  aspect  of  management 
overhead,  the  bandwidth  cost  associated  with  mobility  management. 

This  thesis  provides  a  performance  analysis  of  three  different  mobility 
management  topologies  and  their  associated  protocols  when  used  in  a  LEO  satellite 
constellation.  Simulations  were  developed  to  compare  two  aspects  of  mobility 
management  protocols.  The  first  aspect  was  to  determine  which  is  the  better  location  for 
the  Visitor  Location  Register  (VLR)  and  Authentication  Center,  collocated  with  the 
Home  Location  Register  in  the  terrestrial  gateways  or  placed  on  the  communications 
satellites.  The  second  aspect  compared  three  methods  of  updating  the  VLR,  if  the  VLR  is 
onboard  the  satellite.  Three  different  update  schemes  were  examined:  using  the  standard 
IS-41-C  protocol,  transferring  the  database  from  one  satellite  to  another,  or  discarding  the 
database  and  rebuilding  it  from  scratch. 


XVII 


The  thesis  results  concluded  that  simply  moving  the  VLR  from  the  gateway  to  the 
satellite  did  not  decrease  the  traffic  overhead  associated  with  mobility  management.  In 
fact,  the  amount  of  traffic  increased  about  33  percent.  Moving  the  AC  and  VLR  together 
to  the  satellite  however  decreased  the  traffic  load  by  average  of  10  percent  over  the 
standard  model.  With  the  AC  and  VLR  onboard  the  satellite,  it  is  determined  that 
discarding  the  database  and  rebuilding  it  from  scratch  is  the  best  update  method.  This 
scheme  reduced  the  mobility  management  traffic  by  taking  advantage  of  the  properties  of 
the  satellite  constellation.  These  properties  reduced  total  mobility  traffic  overhead  by  30 
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A  COMPARATIVE  ANALYSIS  OF  MOBILITY  MANAGEMENT 
SCHEMES  IN  A  LOW  EARTH  ORBIT  SATELLITE  NETWORK 

Chapter  1:  Introduction 

"The  beginning  of  knowledge  is  the  discovery  of  something  we  do  not  understand." 

-  Frank  Herbert  (1920-1986) 

1.1.  Background 

As  the  twenty-first  century  begins,  there  is  a  push  to  provide  universal  telephone 
service.  Currently,  the  industrialized  nations  have  approximately  500  telephones  for 
every  thousand  people,  while  developing  nations  lag  far  behind  with  only  about  60 
telephones  for  every  thousand  people  (Figure  1)  [CIA99].  Trying  to  build  a  conventional 
public  switched  telephone  network  (PSTN)  infrastructure  to  give  the  rest  of  the  world  the 
same  communications  availability  as  the  industrial  nations  will  be  too  costly  and  labor 
intensive.  Instead,  the  lofty  goal  of  universal  telecommunications  service  throughout  the 
world  can  only  be  achieved  through  to  use  of  cellular  and  satellite  networks  [Meg97]. 


Figure  1.  Number  of  Telephones  per  1000  people  [CIA99] 


there  were  more  than  45  million  cellular  subscribers  worldwide.  By  the  year  2005,  it  is 
predicted  that  there  will  be  more  than  100  million  subscribers  (Figure  2)  [GSM96],  PCN 
has  the  potential  to  provide  low  cost  connections  in  areas  with  dense  populations,  but  for 
many  rural  areas,  PCN  may  not  be  economically  feasible.  Although  cellular  telephone 
networks  are  wireless  for  the  subscriber,  they  rely  on  a  terrestrial  backbone  to  support 
communications  between  the  other  components  of  the  network,  and  to  connect  the 
subscriber.  This  infrastructure  is  not  cost-effective  if  it  supports  a  limited  number  of 
customers.  In  addition,  PCNs  with  their  fixed  antennas  and  terrestrial  base  stations  cannot 
adequately  cover  the  oceans,  mountainous  regions,  remote  islands  and  other  inaccessible 
areas. 


Figure  2.  Cellular  Subscriber  Growth  Worldwide  [GSM96] 


In  contrast,  Low  Earth  Orbiting  (LEO)  satellites  can  provide  connectivity  anywhere 
in  world,  without  the  need  of  any  terrestrial  components  in  remote  areas.  Satellite 
networks,  like  Iridium®  [IriOO]  and  Globalstar®  [GloOO],  have  recently  begun  operations 
and  are  designed  to  give  mobile  subscribers  (MS)  the  ability  to  place  and  receive  calls 
anytime  from  anyplace.  Providing  this  capability  to  the  mobile  user  requires  the  satellites 
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to  support  the  five  basic  functions  of  a  mobile  network:  mobility  management,  radio 
system  management,  call  processing  management,  terrestrial  transmission  facilities 
management,  and  operations,  administration  and  maintenance  [GaS97]. 

To  explain  each  one  briefly,  mobility  management  comprises  the  functions  needed  to 
enable  the  users  to  be  mobile.  Radio  management  handles  the  radio  resources, 
connections  and  transmission  paths  between  the  mobile  users  and  the  network.  Call 
processing  management  establishes,  maintains,  and  releases  calls  to  and  from  the 
subscriber.  Terrestrial  transmission  facilities  management  works  with  the  physical  means 
of  providing  voice  and  data  communication  interactions  between  the  PSTN  and  the 
satellite  network.  Finally,  operations,  administration  and  maintenance  allow  the  satellite 
network  provider  the  means  to  monitor  and  control  the  network  [GaS97]. 

Satellite  and  cellular  networks  share  the  same  five  functions  of  a  mobile  network,  and 
so  when  the  satellite  systems  were  being  developed,  the  protocols  for  each  of  these 
management  functions  were  transferred  from  the  terrestrial  cellular  environment  into  the 
satellite  arena,  without  any  major  modifications.  However,  satellite  systems  have 
different  limitations  and  strengths  than  a  PCN,  thus  the  best  protocol  for  a  PCN  may  be 
inappropriate  for  a  satellite  system.  This  research  examines  one  aspect  of  network 
management,  mobility  management,  and  determines  if  protocols  based  on  satellite 
properties  are  advantageous,  when  compared  to  those  developed  for  a  PCN. 

1.2.  Research  Goal 

This  research  has  two  goals: 

•  to  compare  the  overhead  associated  with  different  mobility  management  schemes 
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•  to  determine  if  a  topology  taking  in  account  the  strengths  and  weaknesses  of  LEO 
satellites  has  less  overhead  than  a  standard  terrestrial-based  topology. 

1.3.  Research  Motivation 

This  thesis  provides  a  performance  analysis  of  three  different  mobility  management 
topologies  and  their  associated  protocols  when  used  in  a  LEO  satellite  constellation.  The 
subject  of  LEO  satellite-based  communication  networks  is  a  relatively  new  field 
receiving  much  attention.  This  interest  is  generating  a  wealth  of  fresh  topics  for  research, 
since  certain  aspects  of  satellite  operations  are  not  specified  in  literature.  Specifically, 
the  protocols  used  by  the  satellites  for  the  five  basic  mobile  network  functions  are  not 
readily  available,  thus  creating  the  opportunity  for  researchers  to  speculate  on  which  ones 
are  being  used  today,  and  develop  new  protocols  for  the  satellites  of  tomorrow.  The  most 
intriguing  aspect  is  the  homogenous  nature  of  the  current  generation  of  satellite  networks, 
allowing  new  protocols  to  be  tested  without  the  need  to  worry  about  compatibility  issues. 

This  thesis  concentrates  the  area  of  mobility  management.  Mobility  management 
involves  four  major  functions:  intersystem  handoff,  automatic  roaming,  authentication, 
and  call  processing.  The  interactions  between  these  four  areas  create  a  complex  web  that 
defies  finding  an  easy  way  to  derive  an  optimal  solution,  i.e.,  optimization  in  one  area 
usually  leads  to  degradation  in  another.  Reviewing  research  in  terrestrial  cellular 
networks  show  many  possible  options  for  mobility  management.  This  variety  of 
approaches,  coupled  with  the  scarcity  of  information  about  specific  satellite 
implementations  of  mobility  management,  make  an  intriguing  combination. 
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1.4.  Approach 

This  research  used  [Lee97]  as  a  point  of  departure.  In  [Lee97],  two  user  location¬ 
tracking  algorithms  were  investigated  in  the  LEO  environment:  the  gateway  approach 
and  the  satellite  approach.  In  the  gateway  approach ,  the  user  information  database  is 
located  in  the  terrestrial  gateways.  In  the  satellite  approach,  the  information  is 
maintained  on  board  the  satellites.  His  conclusions  indicate  that  the  satellite  approach 
performs  better  than  the  gateway  approach  in  call  setup  delay  and  number  of  hops 
required  to  establish  initial  call  requests. 

This  thesis  first  examines  a  standard  mobility  management  protocol,  Interim 
Standard-41  (IS-41),  currently  used  in  most  of  North  America.  The  protocol  is  changed 
in  four  incremental  steps  to  determine  if  the  protocol  can  be  modified  to  take  advantage 
of  the  LEO  satellite  network's  unique  characteristics  without  losing  compatibility  with  the 
PSTN  and  other  external  networks.  The  first  step  moves  the  Visitor  Location  Register 
(VLR)  from  the  terrestrial  gateways  to  the  satellites.  This  is  followed  by  moving  the 
Authentication  Center  (AC)  from  the  gateways  to  the  satellites.  The  third  step  determines 
the  overhead  associated  with  moving  the  VLR  database  from  one  satellite  to  the  next. 
Finally,  with  the  VLR  and  AC  in  each  of  the  satellites,  a  new  time-based  location 
updating  scheme  is  introduced  where  the  world  is  divided  into  fixed  cells,  and 
intersatellite  communications  eliminate  the  need  for  transferring  the  VLR  database.  Each 
of  these  changes  is  compared  with  the  standard  protocol  model  in  use  today.  The  key 
performance  measure  is  the  amount  of  traffic  generated  by  each  protocol.  However,  the 
number  of  messages  sent,  average  number  of  hops,  and  peak  loading  are  also  examined. 
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1.5.  Overview  of  Results 

This  thesis  shows  that  simply  moving  the  VLR  from  the  gateway  to  the  satellite  does 
not  decrease  traffic  overhead  associated  with  mobility  management.  In  fact,  the  amount 
of  traffic  increases  about  33  percent.  Moving  both  the  AC  and  VLR  to  the  satellite  does 
decrease  the  traffic  load  by  an  average  of  10  percent. 

With  the  AC  and  VLR  residing  in  the  satellite,  this  thesis  shows  that  with  certain 
changes  to  the  protocol,  completely  discarding  the  database  and  rebuilding  it  from  scratch 
is  the  best  method  examined  to  update  the  VLR  database  on  a  satellite.  This  scheme 
reduced  the  mobility  management  traffic  by  taking  advantage  of  the  satellite 
constellation's  properties.  These  properties  allowed  the  total  mobility  traffic  overhead  to 
be  reduced  by  30  percent. 

1.6.  Summary 

This  chapter  introduced  the  goals  of  the  research,  and  provided  some  of  the 
motivation  behind  pursuing  this  line  of  study.  The  chapter  continued  with  a  brief 
synopsis  of  the  foundation  this  thesis  builds  on.  Section  1.5  concluded  this  chapter  by 
presenting  an  overview  of  the  results  from  this  study.  The  following  chapters  will 
provide  more  depth  on  the  facts,  models  and  results  used  to  support  this  thesis. 

Chapter  2  presents  a  review  of  the  current  literature  for  mobility  management  and  low 
earth  orbiting  satellites.  First,  the  many  proposed  and  actual  versions  of  mobility 
management  protocols  used  in  a  terrestrial  cellular  network  environment  are  examined. 
This  is  followed  by  an  overview  of  LEO  satellites,  their  strengths  and  weaknesses,  and 
why  they  are  being  used  for  mobile  communications.  The  chapter  concludes  with  an 
explanation  of  the  use  of  mobility  management  in  low  earth  orbiting  satellites. 


6 


Chapter  3  describes  the  methodology  used  to  compare  the  overhead  associated  with 
different  mobility  management  schemes.  This  includes  the  presentation  of  models 
developed  to  support  the  thesis.  Chapter  4  presents  results  obtained  through  network 
simulation  and  analyzes  it.  Chapter  5  concludes  the  thesis  with  a  discussion  of 
conclusions  and  recommendations  for  areas  of  future  research  in  mobility  management  in 
a  LEO  environment. 
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Chapter  2:  Literature  Survey 


2.1.  Introduction 

This  chapter  examines  the  area  of  mobility  management  in  Low  Earth  Orbiting  (LEO) 
Satellite  systems.  This  specific  field  is  not  well  represented  in  literature,  and  a  Literature 
Survey  cannot  address  it  as  a  unified  topic.  Instead,  it  is  better  to  explain  the  topic  as 
three  separate  areas,  and  then  combine  them  into  a  coherent  subject. 

Section  2.2  provides  a  brief  overview  of  cellular  networks.  This  section  goes  into 
detail  about  how  a  typical  Personal  Communication  Network  (PCN)  is  configured,  and 
explains  its  major  components.  Section  2.3  provides  an  in-depth  discussion  of  the 
mobility  management  schemes  used  in  a  PCN,  concentrating  on  IS-41-C.  Section  2.4 
gives  an  overview  of  satellite  communications  with  special  emphasis  on  LEO  satellites. 
Finally,  Section  2.5  concludes  the  chapter  by  explaining  mobility  management  in  a 
satellite  network. 

2.2.  Wireless  Communications 

"You  see,  wire  telegraph  is  a  kind  of  a  very,  very  long  cat.  You  pull  his  tail  in  New  York 
and  his  head  is  meowing  in  Los  Angeles.  Do  you  understand  this?  And  wireless 
telegraph  operates  exactly  the  same  way:  you  send  signals  here,  they  receive  them 
there.  The  only  difference  is  that  there  is  no  cat." 

-  Albert  Einstein  (1875-1 955) 

2.2.1.  Introduction 

Communications  have  advanced  rapidly  since  1837  when  Samuel  Morse  first 
demonstrated  the  wire  telegraph  in  the  United  States.  Over  the  next  150  years,  the 
telegraph,  telephone,  radio,  and  television  have  become  commonplace.  Wireless 
communications,  both  cellular  and  satellite,  will  soon  be  just  as  ubiquitous. 
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With  each  communication  advance,  new  challenges  must  be  faced  and  overcome. 
Moving  from  a  fixed  communications  system  to  a  mobile  system  is  no  different.  Many 
of  the  basic  assumptions  used  to  build  the  public  switched  telephone  network  (PSTN)  do 
not  hold  in  a  wireless  network.  First,  the  subscribers  in  a  wireless  network  are  not  in  a 
fixed  location.  They  are  usually  mobile  and  may  not  be  located  near  where  their  cellular 
phone  is  registered.  So,  the  network  must  have  the  ability  to  locate  and  route  calls  to  the 
mobile  subscriber  (MS)  quickly  and  efficiently.  Second,  the  network  must  compensate 
for  limited  processing  and  power  capabilities  of  the  small  handheld  radios  used  to 
communicate  with  the  network  [LaS96].  Another  concern  is  that  the  reliability  and 
bandwidth  capacity  of  the  channels  used  in  wireless  system  are  less  than  in  the  PSTN. 
The  network  protocols  must  conserve  bandwidth  and  robustly  handle  errors.  Finally,  the 
user's  equipment  is  low  powered  and  not  physically  attached  to  network,  and  the  network 
doesn't  offer  complete  coverage.  So,  connectivity  between  the  network  and  the  user  may 
possibly  be  sporadic.  The  network  must  be  able  to  tolerate  intermittent  disconnects. 

2.2.2.  Network  configuration 

To  overcome  these  obstacles  and  provide  service  to  the  maximum  number  of 
subscribers  possible,  most  wireless  systems  have  adopted  a  standard  configuration  based 
on  a  cell  architecture  [RoM99].  Figure  3  shows  an  idealized  version  of  a  cell. 


9 


Typically,  it  is  viewed  as  a  hexagon  with  a  base  transmitter  located  in  the  center.  Any 
cellular  telephone  that  is  within  the  hexagon  can  communicate  with  the  base  transceiver. 
A  wireless  system,  like  PCN,  consists  of  a  large  number  of  these  cells.  Figure  4  provides 
an  illustration  of  a  small  PCN  network.  This  PCN  consists  of  fifteen  cells,  each  with  a 
base  transceiver  to  communicate  with  mobile  users.  The  base  transceiver  is  connected  to 
the  other  base  transceivers  through  a  fixed  landline  network  (dark  and  light  connecting 
lines).  Tracing  a  communication  path  on  Figure  4,  a  subscriber  (lower  left  comer)  sets  up 
an  air  link  with  the  base  transmitter  controlling  the  cell  it  is  located  in.  The  signal  is  then 
passed  through  the  landlines  to  the  nearest  base  transmitter  to  receiver  (light  connecting 
lines.  The  signal  is  then  converted  back  to  an  air  link,  and  is  received  by  the  mobile 
user's  handset  (upper  right  comer). 


Figure  4.  Small  PCN 


To  support  the  mobile  subscribers,  the  network  has  to  interface  with  the  MS's 
equipment,  and  be  able  to  connect  users  on  the  PCN  or  the  standard  telephone  system. 
To  perform  all  these  tasks  and  various  bookkeeping  details,  the  PCN  is  composed  of 
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three  major  components:  the  mobile  terminal  equipment,  the  base  station  subsystem,  and 
network  subsystem. 


2.2.2. 1  Mobile  Terminal  Equipment 

The  mobile  terminal  equipment  is  the  equipment  the  subscriber  uses  to  communicate 
with  the  rest  of  the  network.  This  equipment  may  be  a  telephone,  laptop,  fax,  or  other 
communication  device.  It  must  be  small  and  lightweight,  require  little  power  to  transmit, 
and  receive  signals  clearly  using  a  small  omni-directional  antenna  [Lut98].  The 
equipment  must  also  support  the  protocols  of  the  network  to  allow  for  handoffs,  to  update 
its  location,  to  acknowledge  terminal  paging,  and  to  send  and  receive  calls. 

2. 2. 2. 2  Base  Station  Subsystem 

As  discussed  earlier,  current  PCNs  are  designed  using  a  cellular  architecture.  This 
means  a  coverage  area  is  divided  into  a  large  number  of  smaller  areas  called  cells 
[AkH95a].  Because  each  base  transceiver  controls  only  one  cell,  and  transmits  its  signal 
out  a  limited  distance,  the  same  frequency  is  available  for  use  in  others  cell,  located  at 
least  one  cell  away.  A  typical  seven  cell  pattern  is  shown  in  Figure  5.  The  cells  with  the 
same  letter  are  using  the  same  frequency.  This  frequency  reuse  allows  the  cellular 
network  to  support  more  users  with  a  limited  bandwidth. 


Figure  5.  Seven  Cell  Frequency  Reuse 
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Inside  each  of  these  cells  is  a  base  station  subsystem  consisting  of  a  Base  Transceiver 
Station  (BTS)  and  a  Base  Station  Controller  (BSC).  The  BTS  communicates  with  all  the 
mobile  subscribers  within  its  coverage  area  [AkH95b].  In  a  large  urban  area,  the 
potential  exists  for  a  large  number  of  BTSs  to  be  deployed.  The  BSC  manages  the  radio 
resources  for  one  or  more  BTSs.  It  handles  radio  channel  setup,  frequency  hopping,  and 
handovers.  The  BSC  also  translates  the  voice  channel  used  over  the  radio  link  to  the 
standard  64  kbps  channel  used  by  the  PSTN.  In  addition  the  BSC  is  the  connection 
between  the  MS  and  the  Network  Subsystem. 

2.2.23  Network  Subsystem 

The  network  subsystem  is  the  interface  to  the  fixed  landline  network,  and  performs  all 
the  functions  of  a  standard  network  node.  Standard  network  nodes  can  forward  data 
packets  using  a  standard  protocol  like  Internet  Protocol  (IP),  maintain  a  routing  table,  and 
communicate  with  other  nodes.  In  addition,  the  network  subsystem  node  can  verify  the 
service  class  information  of  the  subscriber,  obtain  location  information  and  interpret  the 
routing  information  and  route  the  call.  In  a  PCN,  the  mobile  switching  center  (MSC), 
home  location  register  (HLR),  and  the  visiting  location  register  (VLR)  handle  these 
processes  [JaC95]. 

The  MSC  is  the  central  component  of  the  Network  Subsystem.  It  acts  like  a  normal 
switching  node  of  the  public  telephone  network.  The  MSC  also  provides  all  the 
functionality  needed  to  handle  a  mobile  subscriber,  such  as  registration,  authentication, 
location  updating,  handovers,  and  call  routing  to  a  roaming  subscriber.  The  information 
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needed  to  handle  this  additional  functionality  is  located  in  two  types  of  databases:  the 
HLR  and  the  VLR. 

The  HLR  is  the  database  maintained  by  the  mobile  subscriber’s  service  provider.  It  is 
normally  located  in  the  coverage  area  where  the  mobile  subscriber  spends  a  majority  of 
his  time.  This  register  maintains  all  the  basic  information  about  the  subscriber.  It  usually 
contains  the  telephone  number  of  the  cellular  phone,  the  subscriber’s  billing  information, 
his  authentication  and  profile  information  [HaL98],  and  the  last  known  location  of  the 
subscriber  [Lin97a]. 

The  VLR  contains  selected  administrative  information  from  the  HLR,  necessary  for 
call  control  and  provision  of  the  subscribed  services  for  each  user  currently  located  in  the 
geographical  area  controlled  by  the  VLR.  The  MSC  center  uses  the  information  in  the 
HLR  and  VLR  to  efficiently  route  calls  to  and  from  the  mobile  subscriber  [HaL98]. 

2.2.3.  Challenges 

"Welcome  every  problem  as  an  opportunity.  Each  moment  is  the  great  challenge,  the 

best  thing  that  ever  happened  to  you.  The  more  difficult  the  problem,  the  greater  the 

challenge  in  working  it  out." 

--  Grace  Speare 

2.2.3. 1  Medium 

Creating  a  seamless  wireless  communication  network  is  fraught  with  challenges.  To 
start  with  wireless  communication  is  limited  by  the  medium.  Unlike  wired  networks, 
wireless  networks  operate  in  a  limited  bandwidth.  This  bandwidth  must  support  all  the 
customer  and  management  traffic.  This  limitation  can  be  mitigated  by  dividing  the 
service  area  into  cells  and  reusing  the  frequencies  in  nonadjacent  cells  as  described  in 
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Section  9.  This  requires  the  base  station  and  terminal  to  limit  their  transmission  power  to 
prevent  bleeding  over  into  other  cells. 

Limited  power  is  beneficial  because  it  conserves  battery  power,  but  it  also  leads  to 
increased  shadowing.  Shadowing  is  caused  by  obstacles  between  the  base  station  and  the 
terminal  that  block  the  radio  transmissions,  which  leads  to  fading  and  lost  calls  [Lut98]. 
Another  difficulty  of  wireless  communication  is  multipath  fading.  As  signals  travel 
through  the  air,  there  are  obstacles  that  cause  the  signal  to  reflect.  These  reflections  can 
create  interference  with  the  original  signal  and  cause  this  signal  to  arrive  at  the  receiver  at 
different  time.  The  effect  the  channel  rates  of  the  wireless  link  [AbL97]. 

2.23.2  Mobility 

The  system  must  handle  the  mobility  of  the  users.  Users  will  change  their  network 
attachment  point  over  time.  Therefore,  the  capability  to  gracefully  pass  the 
communication  connection  from  one  network  attachment  to  another  is  needed.  In  a 
packet  switched  network,  new  packets  will  have  to  be  routed  to  the  new  cell,  and  packets 
in  transit  during  handoff  will  have  to  switch  destinations.  Ideally,  this  is  done  without 
delaying  or  losing  any  packets.  If  the  system  is  part  of  an  ATM  network,  then  packets 
must  also  be  kept  in  the  correct  order.  For  a  circuit-switched  network,  the  entire  circuit 
will  have  to  be  rerouted,  again  without  losing  information.  If  losses  do  occur,  then  the 
network  must  be  able  to  recover  gracefully.  The  TCP/IP  protocol  handles  all  packet 
losses  as  if  they  are  caused  by  network  congestion,  which  triggers  recovery  procedures, 
that  reduces  throughput  needlessly  [LaS96]. 
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Another  challenge  is  having  the  channel  capacity  to  accept  handovers.  During  times 
of  heavy  use,  the  cell  may  not  have  the  capacity  to  accept  the  call,  which  will  result  in  a 
forced  termination  [Lin97a].  But  reserving  too  many  channels  for  the  possibility  of  call 
transfers  results  in  preventing  new  calls  from  being  established  (new  call  blocking)  while 
channels  are  idle.  This  reduces  revenue  and  results  in  unsatisfied  customers. 

2. 2. 3. 3  Location  Management 

Even  if  the  terminal  is  not  communicating  during  the  transition  from  one  network 
attachment  to  another,  information  still  needs  to  be  passed  between  the  handset  and  the 
base  station.  Unlike  the  standard  telephone  system,  the  telephone  number  of  a  wireless 
terminal  does  not  signify  the  location  of  the  terminal.  Instead  the  terminal  must  be 
tracked.  Therefore,  as  a  terminal  travels  from  one  spot  to  another,  it  needs  to  inform  the 
network  of  its  new  location  so  that  it  can  receive  incoming  calls.  The  base  station  in  turn 
needs  to  inform  the  handset  of  the  new  frequencies  that  are  used  in  cell  it  is  entering. 

Keeping  track  of  highly  mobile  user  tends  to  waste  bandwidth  and  power  by  sending 
unnecessary  location  updates  [AkH95b].  This  problem  is  compounded  by  the 
tremendous  growth  of  wireless  networks.  With  only  a  limited  number  of  frequencies 
available,  the  networks  are  forced  to  shrink  the  size  of  the  cells  to  increase  capacity  and 
coverage  [ScK99].  As  the  number  of  cells  increase,  so  does  the  signaling  requirement  for 
location  management.  This  increase  in  signaling  reduces  the  bandwidth  available  for 
customers.  It  also  increases  the  number  of  handoffs  and  the  problems  associated  with  it. 

In  addition,  overall  location  management  traffic  generated  between  base  stations, 
mobile  users,  and  management  nodes  imposes  a  significant  burden  on  the  wireline 
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network.  Inter-switch  networking  traffic  can  account  for  up  to  30  percent  of  the  load  on 
the  switches  [DaS97]. 

Another  limitation  to  wireless  communications  is  the  additional  time  required  to  set 
up  calls.  In  most  location  management  schemes  at  least  two  database  lookups  are 
required,  and  then  at  least  one  paging  cycle  must  be  done  before  a  call  can  be  established 
[AbL97]. 

2.3.  Wireless  Location  Management 

"If  you  don't  find  it  in  the  index,  look  very  carefully  through  the  entire  catalogue." 

Sears,  Roebuck,  and  Co., 

Consumer's  Guide,  1897: 


2.3.1.  Introduction 

Providing  the  subscriber  with  the  ability  to  place  or  receive  calls  from  anywhere  in 
the  world  requires  the  PCN  to  carry  out  specific  processes.  The  first  process,  location 
management,  gives  subscribers  the  ability  to  roam  from  one  coverage  area  to  another. 
Location  management  provides  the  network  the  means  to  locate  the  subscriber  as  soon  as 
an  incoming  call  is  made  [Lin97a],  The  second  process,  handoff,  allows  the  network  to 
smoothly  transfer  a  call  when  a  user  moves  from  one  cell  to  another.  Other  important 
processes  supported  by  the  network  include  managing  the  radio  spectrum,  providing 
uniform  coverage,  and  reducing  interference  problems  [JaC95].  This  Section 
concentrates  on  the  investigation  of  Mobility  Management  schemes,  which  includes 
location  management,  paging,  call  setup,  and  call  teardown. 

Mobility  Management  is  defined  as  tracking  all  the  mobile  subscribers  all  the  time. 
So  when  an  incoming  call  arrives,  using  Location  Management,  a  mobile  subscriber  can 
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be  located  and  paged  in  a  cellular  network  within  a  certain  amount  time  [DaS97]. 
Without  a  mobility  management  facility,  wireless  communications  would  be  one-way. 
Mobile  users  could  call  out  but  never  receive  calls.  Currently,  most  PCNs  use  two  basic 
activities  to  handle  Mobility  Management:  location  management  and  terminal  paging 
[DaS97]. 

2.3.2.  Location  Management 

If  a  call  is  made  to  the  mobile  user  before  the  network  is  aware  the  user  exists,  the 
call  is  lost  because  the  network  cannot  route  the  call.  Location  update  is  how  a  mobile 
user  registers  with  the  network  and  lets  the  network  know  its  location.  How  and  when 
the  mobile  user  should  send  out  location  update  messages  has  been  the  subject  of  much 
research  [AkH95a,  AkH95b,  GuR98,  HaL98]. 

With  the  first  wireless  systems,  the  mobile  user  had  to  manually  register  with  the 
local  wireless  service  to  receive  incoming  calls.  If  the  user  entered  a  new  service  area 
without  registering,  the  service  provider  had  no  record  of  his  existence  [NgN98]. 

This  evolved  into  automatic  registration.  Automatic  registration  allows  the  mobile 
terminal  equipment  to  communicate  with  the  base  station  without  manual  intervention. 
Interim  Standard  IS-41  is  the  basis  of  most  automated  location  management  systems  used 
in  the  United  States.  But  location  update  is  only  half  of  the  equation;  the  other  half  is 
terminal  paging. 

2.3.3.  Terminal  Paging. 

When  an  incoming  call  comes  in,  the  network  needs  to  contact  the  mobile  subscriber. 
This  process  is  called  terminal  paging.  The  process  works  as  described  below. 
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A  call  enters  the  PCN  at  one  of  the  switches.  This  originating  switch  looks  at  the 
number  requested,  determines  the  mobile  subscriber's  Home  Location  Register,  and 
queries  the  HLR  for  the  MS's  current  location.  The  HLR,  in  turn,  queries  the  visitor 
location  register  of  the  cell  in  which  the  MS  last  registered.  The  VLR  then  queries  the 
mobile  switching  center  to  determine  if  the  mobile  subscriber  is  able  to  receive  the  call. 
The  mobile  switching  center  sends  out  a  paging  message  to  its  service  area.  Ideally,  the 
mobile  terminal  equipment  hears  and  acknowledges  the  page.  The  MSC  then  assigns  a 
temporary  local  directory  number  (TLDN)  to  the  terminal  and  gives  this  routable  address 
to  the  VLR.  The  VLR  passes  the  TLDN  to  the  HLR,  which  informs  the  originating 
switch.  The  originating  switch  can  now  connect  the  call  [Lin97a]. 

2.3.4.  Location  Update  and  Terminal  Paging  Interaction 

If  bandwidth  and  power  were  not  limiting  factors,  then  every  time  a  mobile  user 
entered  a  new  cell,  it  could  register  with  the  base  station.  This  would  allow  the  network 
to  know  exactly  where  the  user  is  at  all  times,  and  reduce  the  paging  area  to  just  the  one 
cell  [WaJ99].  Under  this  scenario,  the  number  of  registration  updates  is  high  and  the 
traffic  load  on  the  wired  network  between  MSC  and  HLRs  increases.  On  the  other  hand, 
paging  is  minimal  and  performed  very  quickly  [GuR98]. 

At  the  other  extreme,  the  mobile  user  could  conserve  power  by  never  registering  with 
the  network  [NgN98].  Then  when  an  incoming  call  arrived,  the  network  would  send  out 
a  paging  message  to  every  cell  in  the  network.  If  the  mobile  user  is  on,  it  is  found  and 
receives  the  call  [DaS97].  The  system  requires  no  databases,  but  the  paging  flood  has  a 
high  cost  [WaJ99]. 
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But  since  bandwidth  and  power  are  limiting  factors,  cellular  networks  currently  try  to 
minimize  the  average  cost  of  paging  and  registration.  The  modular  nature  of  a  cellular 
network  allows  the  system  to  group  adjacent  cells  together  to  share  the  registration  and 
paging  tasks.  This  group  of  cells  is  called  a  location  area  (LA)[AkH95b]. 

In  a  static  location  area,  all  the  cells  within  the  LA  broadcast  the  same  LA  signature. 
When  a  mobile  user  crosses  an  LA  boundary,  it  detects  the  new  signature  and  sends  a 
location  update  message  [RoM99].  The  user's  location  information  is  then  added  to  the 
VLR,  which  then  forwards  the  information  to  the  HLR  [GuR98].  Then,  as  long  as  the 
user  remains  in  the  same  LA,  it  is  not  required  to  send  any  additionally  location  update 
messages.  When  an  incoming  call  arrives,  the  network  consults  the  HLR,  determines  the 
mobile  user's  LA,  and  sends  a  paging  signal  to  each  cell  of  the  location  area  [AkH95b]. 

A  simple  relationship  exists  between  registration/paging  costs  and  the  size  of  the 
Location  Area.  As  the  size  of  the  LA  increases,  the  cost  of  registering  is  lowered,  but  the 
cost  to  page  all  the  cells  goes  up.  If  the  size  of  the  LA  decreases,  then  mobile  users  have 
to  register  more  often,  increasing  their  cost,  but  the  cost  of  paging  goes  down. 

2.4.  Location  Update  Schemes 

A  person  travels  the  world  over  in  search  of  what  he  needs  and  returns  home  to  find  it. 

George  Moore  ( 1 852- 1 933) 

2.4.1.  Introduction 

An  optimal  solution  attempts  to  minimize  the  total  cost  for  location  management 
without  requiring  excessive  computation  or  communications  costs.  As  mentioned  earlier, 
the  total  cost  can  be  viewed  as  a  tradeoff  between  the  cost  of  registering  mobile  users  and 
the  cost  to  page  the  users  when  there  is  an  incoming  call  [AbL97].  A  good  mobile 
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terminal  tracking  policy  balances  location  update  with  paging  so  that  the  total  cost  is 
minimized  [AkH95b].  This  goal  of  reaching  an  optimal  cost  has  lead  to  research  in 
developing  new  location  update  algorithms,  reducing  paging  costs,  and  reducing  database 
accesses  [AkH95a,  AkH95b,  GuR98,  HaL98].  Some  of  these  schemes  will  be  presented 
in  the  following  sections. 

2.4.2.  Location  Update  Algorithms 

2.4.2. 1  Introduction 

A  majority  of  the  research  in  location  management  has  been  concentrated  on 
developing  better  location  update  algorithms  [Abl97,  AkH95a,  GuR98,  HaL98,  Lin97a]. 
This  area  of  research  is  critical,  since  power  and  computation  limitations  of  mobile 
terminals  have  been  of  paramount  concern.  The  standard  approaches  to  location  update 
can  be  divided  into  two  types:  static  and  dynamic  updates. 

In  static  updates,  the  configuration  of  the  network  is  determined  during  the 
construction  of  the  net.  The  network's  location  areas  are  established,  and  are  not  altered 
while  the  network  is  running.  If  any  changes  are  needed,  they  are  determined  off-line, 
and  are  hard- wired  into  the  system.  In  the  United  States,  IS -41  is  a  common  static 
location  update  algorithm,  but  other  proposed  algorithms  include:  reporting  cell,  time- 
based,  movement-based,  and  distance-based  algorithms. 

Unlike  static  location  update,  dynamic  location  update  is  not  predetermined.  Instead, 
the  mobility  pattern  of  the  mobile  subscriber  and  how  often  it  receives  incoming  calls 
determine  when  it  registers  [AbL97].  This  scheme,  when  implemented  correctly,  can 
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provide  significant  savings  over  static  methods,  but  at  higher  computational  and 
implementation  costs. 

2A.2.2  IS-41 

The  North  American  Standard  IS-41  provides  a  good  benchmark  for  all  location 
management  schemes.  It  is  the  most  extensively  used  scheme  in  the  United  States.  A 
trace  diagram  of  the  IS-41 's  location  update  message  passing  is  presented  in  Figure  6.  In 
IS-41,  cellular  networks  are  divided  in  location  areas.  Each  location  area  broadcasts  a 
unique  signature  on  a  special  frequency  for  mobile  terminal  receivers.  When  the  mobile 
terminal  enters  a  new  location  area,  it  reads  the  new  location  area's  signature,  determines 
it  is  in  a  new  location  area,  and  broadcasts  a  location  update  message.  This  message  is 
received  by  the  base  station,  which  then  passes  the  information  to  the  VLR  of  the  location 
area.  The  VLR  looks  up  the  address  for  the  HLR,  and  requests  verification  of  the  user  as 
a  valid  user.  The  HLR  returns  a  Secret  Shared  Data  (SSD)  field,  which  is  used  to 
authenticate  the  mobile  user.  Upon  authentication,  the  VLR  sends  the  HLR  a  registration 
message  informing  it  that  the  mobile  user  is  now  in  the  VLR's  area.  The  HLR  sends  a 
deregistration  message  to  the  old  VLR  and  then  acknowledges  the  message.  The  mobile 
terminal  is  then  acknowledged  [Lin97a]. 
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Figure  6.  IS-41  Location  Update  Trace  Diagram 

Paging  under  IS-41  is  just  as  straightforward.  The  entire  process  to  setup  a  call  from 
the  PSTN  to  a  mobile  user  is  traced  in  Figure  7.  A  call  enters  the  PCN  at  one  of  the 
switches.  This  originating  switch  looks  at  the  number  requested,  determines  the  mobile 
subscriber's  HLR,  and  queries  the  HLR  for  the  MS's  current  location.  The  HLR  then 
queries  the  visitor  location  register  of  the  cell  in  which  the  MS  last  registered.  The  VLR 
then  queries  the  mobile  switching  center  to  determine  if  the  mobile  subscriber  is  able  to 
receive  the  call.  The  mobile  switching  center  sends  out  a  paging  message  to  its  service 
area.  Ideally,  the  mobile  terminal  equipment  hears  and  acknowledges  the  page.  The  MSC 
then  assigns  a  temporary  local  directory  number  (TLDN)  to  the  terminal  and  gives  this 
the  routable  address  to  the  VLR.  The  VLR  passes  the  TLDN  to  the  HLR,  which  informs 
the  originating  switch.  The  originating  switch  can  then  connects  the  call  [Lin97a]. 
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Figure  7.  IS-41  PSTN  to  MS  Call  Setup 


2. 4. 2. 3  Time-Based  Location  Update 

Time-based  location  update  is  one  of  the  simplest  location  update  schemes.  After 
waiting  a  specific  amount  of  time,  the  mobile  terminal  sends  out  a  location  update 
message  [DaS97].  The  virtue  of  this  scheme  is  that  it  requires  no  external  stimulus, 
needing  only  an  internal  clock  or  countdown  timer  for  updating.  Time-based  updating 
also  provides  predictable  updates,  which  are  advantageous,  when  either  the  HLR  or  VLR 
are  not  reliable  [HaL98].  The  downside  is  that  many  location  update  messages  are  sent 
even  when  the  mobile  user  is  stationary.  This  wastes  both  communication  bandwidth  and 
terminal  power.  Another  problem  associated  with  time-based  update  is  the  size  of  the 
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paging  area.  A  fast  moving  user  can  be  many  miles  from  its  last  updated  location  and  can 
be  difficult  to  find. 

The  newer  time-based  variations  are  dynamic  and  allow  the  time  interval  to  be 
adjusted  according  to  the  expected  frequency  of  incoming  calls.  Optimally,  this  allows 
the  terminal  equipment  to  predict  when  the  next  call  will  be  received  and  send  out  a 
location  update  message  just  before  the  HLR  needs  it.  In  [HaL98],  it  is  shown  that  the 
reliability  of  the  home  location  register  is  also  a  factor  in  determining  how  often  a  mobile 
terminal  should  update.  If  the  HLR  is  unreliable,  then  updates  should  be  done  more  often 
than  the  average  time  between  incoming  calls.  Otherwise  the  updates  should  occur 
approximately  once  between  calls. 

2. 4. 2. 4  Movement-Based  Locatio  n  Update 

Another  simple  location  update  algorithm  is  movement-based  location  update.  In  this 
scheme,  the  terminal  monitors  the  broadcast  signature  of  the  cell's  base  station.  Every 
time  a  different  signature  becomes  the  strongest,  the  user  knows  that  it  has  entered  a  new 
cell,  and  updates  in  cell  number.  After  the  terminal  crossed  a  predetermined  number  of 
cells  («),  it  sends  out  a  location  update  message  [AhK95].  The  paging  area  is  easy  to 
calculate  since  the  MS  can  only  be  up  to  n  cells  away.  As  Figure  8  shows,  if  n  is  4  and 
the  cellular  network  is  hexagonal,  then  the  paging  area  contains  61  cells.  This  number 
can  be  calculated  from  Equation  1 . 

Cellmd=\+  ±6x  (1) 

x=0 
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Figure  8.  MS  Movement  (n=4) 


This  scheme  is  effective  since  it  reduces  the  number  of  update  messages  sent  by  a 
stationary  or  slow-moving  terminal.  It  is  also  widely  used  since  it  requires  only  limited 
computation  resources  and  is  easy  to  implement. 

The  chief  disadvantage  of  movement-based  location  update  include  an  excessive 
number  of  update  messages  are  sent  if  the  terminal  is  moving  quickly  and  the  number  of 
incoming  calls  is  low  [AkH96].  Another  disadvantage  is  a  higher  paging  cost.  Since  the 
terminal  does  not  update  every  time  it  enters  a  location  area,  its  location  is  not  precisely 
known.  When  the  network  receives  an  incoming  call,  it  must  search  for  the  terminal  by 
sending  polling  signals  to  all  the  cells  in  the  vicinity  of  the  last  known  location  [AkH96]. 
Another  concern  is  that  if  the  terminal  is  on  the  boundary  between  two  cells,  that  it  would 
often  bounce  between  the  two  signatures.  This  causes  many  messages  to  be  generate 
when  in  turns  wastes  significant  bandwidth,  processing  power  and  power  output 
[AhK95]. 
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2.4.2. 5  Distributed  HLR  with  Two  Locution  Areas 

Distributed  HLR  with  Two  Location  Areas  (HLR/TLA)  is  designed  to  address  some 
of  the  concerns  with  movement-based  location  update.  The  mobile  subscriber  has  a  small 
built-in  memory  to  store  addresses  for  the  two  most  recently  visited  location  areas.  The 

HLR  also  has  an  extra  field.  The  HLR  also  store  the  two  most  recently  reported  location 
areas  [Lin97a], 

The  advantage  of  HLR/TLA  is  that  the  MS  does  not  register  if  it  moves  back  to  a 
previously  visited  location  area.  If  a  user  is  bouncing  between  two  location  areas,  no 
registration  is  needed.  When  there  is  an  incoming  call,  the  HLR  pages  the  last  reported 
location  area.  If  the  user  is  found  then  the  cost  is  the  same  as  IS-41.  If  the  user  is  not 
found,  the  second  location  area  is  then  paged.  The  scheme  outperforms  IS-41  when  call- 

to-mobihty  ratio  is  low  (i.e.  when  the  user  moves  more  often  than  receives  calls)  or  when 
registration  costs  are  high. 

The  disadvantage  of  HLR/TLA  is  that  its  performance  degrades  when  the  users  are 
highly  mobile,  and  do  not  remain  in  a  two  LA  region.  Also,  the  scheme  is  not 
appropriate  in  wireless  communication  systems  that  have  high  paging  cost  and  low 
registration  costs  [Lin97a]. 

2. 4. 2. 6  Reporting  Cells 

Another  proposed  scheme  is  to  establish  two  different  types  of  cells:  Passive  cells  and 
reporting  cells  [BaK93].  Passive  cells,  do  not  send  out  a  signature  signal,  and  do  not 
accept  registrations  except  for  initial  registrations.  All  registration  is  done  when  entering 
a  reporting  cell.  When  the  reporting  cells  are  chosen  correctly,  the  number  of 
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registrations  can  be  less  than  other  schemes.  It  has  an  advantage  over  movement-based 
since  there  can  never  exist  the  Ping-Pong  scenario  between  two  cells.  It  has  an  advantage 
over  time-based  schemes,  if  the  mobile  user  does  not  move.  In  this  scenario,  no  updates 
are  needed. 

The  disadvantages  of  reporting  cells  are  many.  The  biggest  is  that  there  is  a 
possibility  that  a  mobile  subscriber  can  move  across  the  network  without  ever  hitting  a 
reporting  cell.  If  this  happens,  the  user  cannot  be  found.  This  defeats  the  purpose  of 
location  management  [BaK93]. 

2.4.2. 7  Distance-Based  Location  Update 

The  fourth  basic  location  update  algorithm  is  based  on  the  distance  a  mobile  user 
travels.  The  terminal  equipment,  using  its  knowledge  of  the  topology  of  the  cells 
[AkH95],  sends  a  location  update  message  only  after  the  exceeding  a  threshold  distance 
(d)  between  the  current  cell  and  the  cell  where  it  sent  the  last  location  update  message 
[AbL97].  This  guarantees  that  the  user  is  never  farther  than  distance  d  from  the  last 
reporting  cell.  The  paging  area  is  again  easily  calculated  by  paging  all  the  cells  within  d 
of  the  reporting  cell. 

Distance-Based  location  update  algorithm's  chief  advantage  is  that  generates  2.5 
times  less  update  messages  than  either  time  or  movement-based  systems.  So 
theoretically,  it  provides  the  best  location  update  and  paging  costs  [AbL97]. 
Unfortunately,  this  algorithm  has  the  highest  overhead,  and  requires  both  the  network  and 
the  terminal  to  know  how  to  calculate  the  distance.  This  is  performed  either  by  knowing 
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the  topology  of  the  network  or  having  a  way  to  know  the  distance  traveled  by  the 
terminal. 

2. 4. 2. 8  Distance-Based  Dynamic  Location  Tracking 

All  the  location  update  algorithms  discussed  so  far  have  been  static.  Newer 
algorithms  provide  a  dynamic  component,  which  allows  it  to  change  the  frequency  of  the 
update  messages  based  on  the  characteristics  of  the  individual  terminal.  The  key  idea  is 
to  optimize  the  algorithm  to  allow  the  terminal  update  its  location  just  before  the  update 
cost  is  greater  than  the  cost  to  page  to  terminal  [AkH95a]. 

The  first  dynamic  location  scheme  discussed  is  the  distance-based  dynamic  location 
tracking.  This  method  uses  the  cost  for  terminal  paging,  cost  for  location  updating  and 
the  distribution  of  incoming  calls  to  calculate  the  distance  ( d)  the  mobile  subscriber  can 
travel  before  it  needs  to  send  a  location  update  message  [AkH95b].  This  process  is 
computationally  intense,  but  mitigates  this  by  calculating  a  new  distance  (d)  only  when 
one  of  the  three  system  parameters  changes.  Otherwise,  the  distance  remains  constant. 

This  offers  the  advantage  of  optimizing  the  cost  for  location  management.  It  also 
makes  the  complexity  of  the  algorithm  is  independent  of  the  system  parameter  values 
[AkH95b].  But,  this  method  has  disadvantages.  Even  though  the  computational 
overhead  is  reduced  due  to  infrequent  distance  recalculation,  it  is  still  computational 
intensive  when  the  calculation  is  done.  The  method  also  requires  additional  bandwidth  to 
inform  the  network  of  the  distance  being  used.  Finally,  the  mobile  subscriber's 
equipment  must  be  able  to  determine  the  distance  traveled. 
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2. 4. 2. 9  Dynamic  Predictive  Location  Management 

Another  dynamic  scheme  that  has  been  proposed  is  based  on  the  fact  the  mobile 
movement  has  regularity  [GuR98].  If  the  class  of  transportation  (foot,  car,  plane)  of  the 
mobile  user  is  known,  then  there  is  knowledge  of  user  movement  constraints.  Using  this 
information  and  the  incoming  call  arrival  rate,  the  shape  of  the  location  area  can  be 
dynamically  tailored  to  match  each  individual's  movement  pattern. 

This  leads  a  hierarchical  cellular  structure,  with  the  each  user  given  a  different  shape 
and  size  of  LA.  This  is  done  by  creating  a  transition  probability  matrix.  The  matrix 
considers  layout  of  the  streets  and  highways,  the  incoming  traffic  patterns  and  the  user's 
mobility. 

From  the  probability  matrix,  an  optimal  location  area  is  created,  and  stored  in  the 
HLR.  This  information  is  then  communicated  to  the  mobile  user  as  a  list  of  cell 
identifications  (IDs)  that  are  in  the  current  LA.  The  user  maintains  this  list  of  cell  IDs, 
and  monitors  the  strongest  broadcast  channel.  When  the  cell  ID  on  the  broadcast  channel 
is  not  in  the  user's  list,  then  it  is  time  to  send  a  location  update  message.  The  message  not 
only  provides  the  network  with  the  user  current  location,  but  also  the  dwell  time  the  user 
spent  in  each  cell  of  the  previous  LA.  In  return,  the  HLR  calculates  a  new  LA  and  sends 
a  new  list  of  cell  ids  in  the  new  location  area  [GuR98]. 

This  system  works  well  if  the  movements  of  the  user  are  predictable.  The  location 
updating  and  paging  cost  is  kept  low,  since  the  LA  includes  only  the  cells  that  are  most 
likely  to  be  visited.  Another  advantage  of  the  scheme  is  the  computational  complexity  is 
removed  from  the  mobile  terminal  and  placed  in  the  computationally  unrestricted  HLR. 
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Unfortunately,  if  the  user's  movements  are  more  random,  the  scheme  breaks  down  and 
does  not  provided  a  noticeable  improvement. 

2.4.3.  Terminal  Paging  Schemes 

2.4.3. 1  Introduction 

So  far  emphasis  has  been  placed  on  the  various  methods  of  improving  the  registration 
of  the  mobile  user.  The  second  task  required  for  mobile  communications  is  terminal 
paging.  Terminal  paging  is  finding  the  mobile  user  when  there  is  an  incoming  call. 

The  simplest  type  of  paging  is  network  flooding.  When  an  incoming  call  is  received, 
every  cell  in  the  network  is  paged  for  the  mobile  user.  This  method  generates  an 
unacceptably  high  traffic  load  on  the  wireless  network.  Imagine  the  Teledesic  system, 
with  over  20,000  cells,  paging  each  of  them  for  one  user.  Instead,  most  current  systems, 
like  IS-41,  page  only  in  the  last  reported  LA  of  the  mobile  user  [GuR98].  But,  a  typical 
LA  has  60  cells,  so  there  is  still  room  for  improvement. 

2.43.2  Multi-step  paging 

Researchers  have  concentrated  on  investigating  the  maximum  paging  delay  [AkH95a, 
AkH95b,  and  GuR98].  This  research  examines  how  much  delay  can  be  tolerated  by  the 
customer  when  finding  terminal.  By  increasing  the  maximum  paging  delay  to  allow  two 
or  three  paging  calls,  the  paging  area  can  be  decreased.  This  is  the  basic  premise  behind 
multi-step  paging. 

There  are  two  major  types  of  multi-step  paging:  static  location  and  shortest-distance- 
first.  In  static  location,  the  location  area  is  subdivided  into  equal  sized  subregions.  The 
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number  of  subregions  is  determined  by  the  number  of  paging  cycles  allowed.  When  an 
incoming  call  is  received,  the  subregion  where  the  MS  registered  is  paged  first,  then  the 
rest  of  the  subregions  in  the  location  area  are  paged  in  any  order.  The  scheme  is  best 
used  with  any  location  update  scheme  that  uses  LAs  as  a  basis. 

The  shortest-distance-first  does  not  divide  the  area  in  specific  subregions.  The  area  is 
split  into  rings  surrounding  the  cell  where  the  user  is  registered.  The  number  of  rings  is 
based  on  the  number  of  paging  cycles  that  can  be  made  within  the  maximum  paging 
delay.  The  ring  closest  to  the  center  cell  is  paged  first,  then  the  page  is  propagated 
outward  until  the  MS  is  found  or  time  expires  [AkH95a].  This  paging  scheme  works  well 
with  distance-based  or  movement-based  location  updates. 

By  allowing  multiple  paging  cycles,  the  average  total  costs  are  reduced  significantly. 
Even  increasing  the  paging  cycle  from  one  to  two  cycles  makes  a  big  difference 
[AkH95a].  Multi-step  paging  increases  in  use,  as  networks  struggle  to  reduce 
management  bandwidth. 

2.4.4.  Database  Architectures 

2.4.4. 1  Introduction 

Another  way  to  reduce  the  cost  of  location  management  is  to  reduce  the  cost  of 
updating  or  finding  the  mobile  user  in  the  database.  As  mentioned  earlier,  most  location 
schemes  use  two  types  of  databases:  the  HLR  and  the  VLR.  The  architecture  used  to 
deploy  these  databases  can  either  be  centralized  or  distributed. 
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2. 4. 4. 2  Centralized  Database 


Centralized  databases  were  established  first.  They  use  simple  algorithms  and  are  easy 
to  implement.  The  chief  disadvantage  to  a  centralized  database  is  that  it  is  hard  to  store 
all  the  mobile  subscriber  information  in  one  database.  As  the  network  grows  to  support 
more  subscribers,  the  load  on  the  database  increases  as  multiple  users  try  to  access  the 
database  simultaneously.  Finally,  if  the  database  is  inaccessible,  the  entire  network  goes 
down  [WaJ99]. 

2. 4. 4. 3  Decentralized  Database 

Recognizing  these  disadvantages,  decentralized  databases  have  become  more 
prevalent.  The  most  common  configuration  consists  of  a  HLR  and  VLR  in  each  location 
area.  This  does  not  reduce  the  amount  of  network  traffic,  but  distributes  it,  and  reduces 
the  likelihood  of  a  database  being  a  bottleneck.  To  connect  a  call  to  a  mobile  subscriber, 
the  wireless  network  switch  uses  the  mobile  subscriber's  number  to  find  the  HLR.  The 
HLR  then  retrieves  the  subscriber's  location,  and  passes  the  information  to  the  switch. 
The  switch  can  then  put  through  the  call  [WaJ99]. 

2. 4. 4. 4  Distributed  HLR/TLC 

A  variation  to  a  distributed  database  that  tries  to  limit  the  number  of  database 
accesses  is  the  Distributed  Home  Location  Register  and  Temporary  Location  Cache 
(HLR/TLC).  In  this  scheme,  there  is  no  VLR.  Instead,  all  the  information  is  kept  in  the 
HLR,  and  so  only  one  lookup  is  required.  This  can  lead  to  a  20  to  40  percent  reduction  in 
wired  network  traffic  [LaS96].  The  downside  is  that  whenever  the  MS  moves,  the  HLR 
must  be  updated.  One  way  to  decrease  the  network  traffic  is  to  keep  a  TLC  at  each  of  the 
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signal  transfer  points  (STP).  Once  information  about  a  user  is  retrieved  from  the  HLR, 
the  information  is  kept  in  a  cache.  Therefore,  when  the  information  is  needed  for  another 
call,  the  information  is  retrieved  from  the  TLC  instead  of  querying  the  HLR  [LaS96]. 
This  system  is  further  improved  by  allowing  any  STP  in  the  path  between  the  switch  and 
the  destination  to  also  store  this  information  in  its  cache.  This  eliminates  the  need  to 
query  the  HLR  if  it  receives  an  incoming  call  to  the  same  mobile  subscriber. 

The  disadvantage  to  this  scheme  is  the  possibility  of  stale  data.  Since  the  HLR  is  not 
queried  every  time,  there  is  a  chance  that  the  MS  has  moved  and  the  information  in  the 
cache  is  incorrect.  This  leads  to  the  switch  being  unable  to  find  the  user,  and  then  must 
query  the  HLR.  The  signal  load  and  connection  time  increases.  If  the  local  call  to 
mobility  ratio  is  greater  than  5,  then  the  signal  load  and  connection  time  is  reduced  when 
compared  to  the  standard  model  [LaS96]. 

2.5.  Introduction  to  Satellites 

"Satellites  are  invisible  to  the  naked  eye  and  therefore  can  have  no  influence  on  the 

Earth  and  therefore  would  be  useless  and  therefore  do  not  exist." 

Francesco  Sizi,  quoted  by  T.  Cox 

2.5.1.  Introduction 

Wireless  communications  based  on  cellular  technology  has  made  great  in-roads  in  the 
developed  nations  with  over  200  million  subscribers  worldwide  [Evo97].  The  biggest 
deterrent  to  cellular  technology  becoming  more  prevalent  in  developing  countries  is  the 
need  for  a  wired  backbone.  Satellites  can  eliminate  this  need.  Other  advantages  for 
satellites  include  their  global  coverage,  and  that  they  can  act  as  an  extension  to  cell, 
mobile,  and  terrestrial  public  switched  telephone  networks  [ChG98]. 
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2.5.2.  Geosynchronous  Satellites 

The  science  fiction  writer  Arthur  C.  Clark  first  suggested  the  concept  of  using 
geosynchronous  satellites  (GEOs)  for  communications  purposes  in  1945.  Satellites  of 
this  type  are  positioned  over  the  equator  at  an  altitude  of  35,786  kilometers  and  match  the 
speed  on  the  Earth's  rotation.  This  allows  the  satellite  to  appear  motionless  to  an  earth 
observer.  GEOs  offer  several  advantages  over  land-based  communications  systems. 
Rapid  two-way  communications  can  be  established  over  wide  areas  with  only  a  single 
relay  in  space  [Evo97].  With  three  satellites  spaced  120  degrees  apart,  worldwide 
coverage  from  70  degrees  north  latitude  to  70  degrees  south  latitude  can  be  provided 
[GaK98].  Earth  stations  can  be  set  up  and  moved  quickly.  Furthermore,  satellite  systems 
are  virtually  immune  to  impairments  such  as  multipath  fading  [Evo97].  The 
disadvantages  of  GEOs  are  the  relatively  long  propagation  delay  of  560ms  [GaK98],  high 
transmitter-power  requirements,  and  poor  coverage  at  the  far  northern  and  southern 
latitudes.  Moreover,  GEOs  are  expensive  to  launch  and  because  only  a  handful  of 
satellites  are  typically  used  to  achieve  global  coverage,  they  are  vulnerable  to  single  point 
of  failure. 

2.5.3.  Low  Earth  Orbiting  Satellites 

The  GEO  disadvantages  have  led  to  interest  in  non-geosynchronous  satellites.  Recent 
research  has  examined  the  use  of  low  earth  orbiting  satellites  (LEOs)  [GaK98,  Gav97, 
Lee97].  LEOs  orbit  the  earth  at  between  700  and  2000  kilometers  and  offer  several 
advantages  over  GEOs.  First,  they  are  smaller,  lighter  and  cheaper  to  launch  [Lut98]. 
Being  in  a  lower  orbit,  they  have  reduced  propagation  delay  and  lower  transmit-power 
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requirements.  This  allows  users  to  communicate  with  small  handheld  terminals  having 
omni-directional  antennas.  However,  at  LEO  altitudes,  a  communications  system 
requires  more  satellites  to  achieve  global  coverage  (see  Table  1).  In  addition,  satellite 
movement  relative  to  the  ground  terminal  introduces  Doppler  shift  in  the  received  signal, 
and  each  satellite  is  visible  from  a  ground  terminal  for  only  about  8  to  10  minutes  at  a 
time  so  that  handoffs  between  satellites  are  frequent  [Evo97]. 

Table  1.  Number  of  Satellites  for  Coverage  [GaK98] 


Satellite  Altitude 
(kilometers) 

500 

135 

700 

88 

1,000 

60 

2,000 

28 

jHHH 

15 

|  35,786 

3 

Nevertheless,  the  majority  of  the  new  satellite  systems  coming  on  line  in  the  next  10 
years  will  be  LEOs.  Not  all  LEOs  are  the  same,  and  can  be  categorized  into  as  big,  little 
and  broadband. 

The  big  LEOs  support  voice  and  data  communications  with  large  satellites,  typically 
weighing  between  400  to  2,000  kilograms  and  operating  at  frequencies  about  1  GHz. 
Examples  of  these  are  Iridium®  and  Globalstar®.  Iridium®  consists  of  66  satellites 
arranged  in  six  planes,  all  in  a  nearly  polar  orbit.  Each  satellite  has  four  intersatellite 
links  and  can  route  voice  and  data  traffic  through  other  satellites  in  the  constellation, 
reducing  the  number  of  gateways  needed. 
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Globalstar  is  a  digital  telecommunications  system  that  offers  wireless  telephone,  data, 
paging,  fax  and  position  location  services  worldwide.  The  48-satellite  constellation  is  not 
as  sophisticated  as  Iridium®  as  it  offers  only  "bent-pipe"  relays  to  the  local  ground-based 
infrastructure. 

The  little  LEOs  use  much  smaller  satellites,  weighing  between  40  and  100  kilograms, 
and  operate  in  the  UHF  and  VHF  bands.  Using  the  lower  bands,  the  transmission 
equipment  on  the  satellite  and  ground  stations  is  cheaper.  Orbcomm,  STARNET,  and 
VITASET  are  examples  of  little  LEO  systems  [GaK98,  Lee99]. 

The  final  category  of  LEOs  is  broadband.  Teledesic  is  the  sole  example  of  this  type 
of  system.  It  is  intended  to  provide  broadband  wireless  data  communications  with 
stationary  terminals  at  ISDN  rates  (1.544  Mbps).  Like  Iridium,  it  has  inter-satellite  links, 
but  it  has  eight  rather  than  four  inter-satellite  links. 

This  thesis  uses  the  Iridium  constellation  for  the  simulation  model.  Section  2.6  will 
explain  the  constellation  more  thoroughly. 

2.6.  Iridium 

2.6.1.  Overview 

Iridium,  named  after  the  atom  with  77  orbiting  electrons,  was  developed  by  an 
international  consortium  of  telecommunications  companies,  including  Motorola, 
Raytheon,  Siemens,  Telesat  and  Bechtel  [Fos98b].  The  system  began  in  1987,  when 
research  began  on  developing  a  low  earth  orbit  (LEO)  satellite  constellation  that  could 
communicate  directly  with  telephones.  The  constellation  was  based  on  a  study  by 
William  S.  Adams  and  Leonard  Rider  of  the  Aerospace  Corporation,  who  published  a 
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paper  in  The  Journal  of  the  Astronautical  Sciences  in  1987  on  the  configurations  of 
circular,  polar  satellite  constellations  at  various  altitudes  providing  continuous,  full-earth 
coverage  with  a  minimum  number  of  satellites.  However,  by  1992  several  modifications 
had  been  made  to  the  system,  including  a  reduction  in  the  number  of  satellites  from  77  to 
66  by  the  elimination  of  one  orbital  plane  [Nel98].  The  satellites  are  coordinated  by  a 
network  of  terrestrial  gateways  connecting  the  satellite  system  to  the  existing  public 
switched  telephone  network.  Starting  on  May  5,  1997,  the  entire  constellation  was 
deployed  within  twelve  months  on  launch  vehicles  from  three  nations:  the  U.S.  Delta  II, 
the  Russian  Proton,  and  the  Chinese  Long  March.  The  final  complement  of  five  satellites 
was  launched  aboard  a  Delta  II  rocket  on  May  17,  1998.  Commercial  service  officially 
began  November  1,  1998. 

2.6.2.  Technology 

The  Iridium  constellation  consists  of  66  satellites  in  near-polar  circular  orbits  inclined 
at  86.4°.  The  66  satellites  are  arranged  in  six  planes,  each  plane  containing  1 1  satellites. 
The  co-rotating  planes  spaced  31.6  degrees  apart  and  counter-rotating  planes  spaced  22 
degrees  apart,  at  an  altitude  of  780  km  [PrR99].  The  altitude  range  considered  for  the 
satellite  system  ranged  for  370  km  and  1100km.  The  lower  limit  marks  where  the 
atmosphere  becomes  substantial  enough  to  require  onboard  propulsion,  and  extensive 
stationkeeping  to  keep  the  satellites  from  leaving  orbit.  The  upper  limit  marks  the 
beginning  of  the  Van  Allen  radiation  belts.  Extensive  shielding  is  required  on  the 
satellite  if  they  fly  above  the  radiation  protection  blanket  provided  by  the  belts.  The  final 
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altitude  was  reached  by  cost  considerations,  which  limited  the  constellation  to  66 
satellites.  [Nel98] 

With  the  satellites  at  780  kilometers  above  the  Earth,  a  satellite  completes  an  orbit 
every  100  minutes  and  28  seconds  [BrR96].  With  the  circumference  of  the  Earth  being 
approximately  40,161  km,  the  ground  speed  of  the  satellite  is  approximately  24,000  km 
per  hour.  This  speed  limits  the  in-view  time  of  a  stationary  customer  to  about  9  minutes 
and  6  seconds. 

Each  satellite  covers  a  circular  area  roughly  the  size  of  the  United  States  with  a 
diameter  of  about  4400  km,  having  an  elevation  angle  of  8.2°  at  the  perimeter  and 
subtending  an  angle  of  39.8°  with  respect  to  the  center  of  the  earth.  A  more  precise 
measurement  was  calculated  by  Fossa  [Fos98b]  as  15,299,900  km  ,  which  equates  to  a 
footprint  radius  of  2209  km  (diameter  4418km).  This  coverage  area  is  divided  into  48 
cells.  The  satellite  has  three  main  beam  phased  array  antennas,  each  of  which  serves  16 
cells  [WooOO].  The  same  antenna  doesn't  service  the  same  cell  for  the  entire  in-view  time. 
Instead,  the  antennas  walk  from  one  cell  to  another  as  the  satellite  moves.  Each  antenna 
illuminates  are  specific  cell  for  approximately  one  minute.  Complex  protocols  are 
required  to  provide  continuity  of  communication  seamlessly  as  handover  is  passed  from 
cell  to  cell  and  from  satellite  to  satellite.  The  communications  link  requires  3.5  million 
lines  of  software,  while  an  additional  14  million  lines  of  code  are  required  for  navigation 
and  switching.  As  satellites  converge  near  the  poles,  redundant  beams  are  shut  off.  There 
are  approximately  2150  active  beams  over  the  globe. 

The  Iridium  system  is  not  just  satellite  constellation;  it  is  a  complete  network 
consisting  of  satellites,  gateways,  and  user  handsets. 
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2.6.3.  Satellites 


The  Iridium  network  uses  a  more  sophisticated  satellite  than  has  been  deployed  up  to 
this  point  (Figure  9).  Instead  of  the  typical  "bent  pipe"  configuration,  similar  to 
Globalstar  and  other  competitors,  Motorola  went  with  a  satellite  that  has  the  capability  to 
communicate  with  other  satellites  in  the  constellation.  The  communication  is 
accomplished  using  intersatellite  links  (ISLs).  This  capability  allows  the  network  to 
route  calls  from  one  subscriber  to  another  without  every  using  a  terrestrial  links. 
Unfortunately,  this  capability  increases  the  weight,  cost  and  complexity  of  each  of  the 
satellites.  A  satellite  weighs  approximately  680  kg,  is  13  meters  in  length  and  4  meters  in 
width.  A  total  of  125  satellites  have  been  ordered  from  Lockheed  Martin  for  more  than 
$700,000,000  [JPL00].  The  total  cost  of  this  endeavor  is  estimated  at  $3.45  billion. 

IftlOtUM  SATELLITE 
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Battery 
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Figure  9.  Iridium  Satellite 
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The  satellite's  internal  guidance  is  controlled  by  gyroscopes  in  a  3-axis  stabilized 
configuration.  This  is  supplemented  by  a  hydrazine  propulsion  system.  Power  to  the 
satellite  is  provided  by  two  solar  panels  on  a  1  axis  articulation.  Designed  to  last  8  years, 
the  expected  life  span  is  five  years. 

Each  satellite  has  a  capacity  of  about  1100  channels.  However,  the  actual  number  of 
users  within  a  satellite  coverage  area  will  vary  and  the  distribution  of  traffic  among  cells 
is  not  symmetrical. 

Gateways 

The  connection  between  the  Iridium  system  and  land-based  public-switched 
telephone  networks  (PSTNs)  is  achieved  by  Iridium  gateways.  The  Iridium  constellation 
is  connected  to  the  gateway  using  high-gain,  3.048-m-diameter  parabolic  tracking 
antennas  operating  at  Ka-band  frequencies  with  the  uplink  operating  at  29. 1  to  29.3  GHz 
and  the  downlink  at  19.4  to  19.6  GHz.  The  antennas  are  housed  in  radomes 
approximately  5  m  in  diameter.  These  co-located  antennas  will  provide  the  necessary 
geographic  diversity  to  overcome  weather  as  well  as  atmospheric  signal  fading  and 
blocking. 

At  the  heart  of  an  Iridium  gateway  is  the  mobile  switching  center  (MSC),  a  Siemens 
GSM-D900  switch.  The  MSC  has  two  "sides:"  a  land  side,  which  connects  to  the  local 
telephone  network,  and  a  mobile  side,  which  connects  to  an  earth  terminal  controller 
(ETC).  The  ETC  is  analogous  to  the  base-station  system  of  a  terrestrial  GSM  system  and 
it  controls  a  set  of  earth  terminals  (ETs)  which  communicates  with  the  constellation  using 
K-band  radio  links.  Information  for  physical  subscriber  equipment  is  kept  in  the 
equipment  identification  register  (EIR). 
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The  gateway  message  origination  controller  (MOC)  supports  a  variety  of  messaging 
services,  such  as  direct  messaging  to  Iridium  pagers.  The  gateway-management  system 
(GMS)  provides  operational,  administration  and  maintenance  support  for  each  of  the 
gateway  subsystems.  [Bro96] 

User  Handsets 

The  Iridium  handsets  are  built  by  Motorola  and  Kyocera,  a  leading  manufacturer  of 
cellular  telephones  in  Japan.  Handsets  will  permit  both  satellite  access  and  terrestrial 
cellular  roaming  capability  within  the  same  unit.  The  unit  also  includes  a  Subscriber 
Identity  Module  (SIM)  card.  Major  regional  cellular  standards,  like  IS-41  and  GSM,  are 
interchanged  by  inserting  a  different  Cellular  Cassette.  Paging  options  are  available,  as 
well  as  separate  compact  Iridium  pagers  [Flo93].  Current  pricing  is  $1399  for  the 
handset,  $199  to  activate  the  service  and  then  a  $19  service  charge  each  month.  In 
addition  the  cost  of  a  call  ranges  from  $1.79  to  $4.79  [TelOO].  Most  Iridium  handset  will 
be  designed  to  be  dual-mode.  This  means  that  not  only  with  the  user  be  able  to 
communicate  with  the  Iridium  satellite,  but  also,  with  the  local  cellular  network,  if 
available. 

The  handsets,  when  communicating  with  the  satellites,  operate  in  the  L-band, 
specifically  1621.35  to  1626.5  MHz.  This  5.15  MHz  bandwidth  is  divided  into  120 
FDMA  channels,  each  with  a  bandwidth  of  31.5  kHz  and  a  guardband  of  10.17  kHz  to 
minimize  intermodulation  effects  and  two  guardbands  of  37.5  kHz  to  allow  for  Doppler 
frequency  shifts.  Within  each  FDMA  channel,  there  are  four  TDMA  slots  in  each 
direction  (uplink  and  downlink).  The  coded  data  burst  rate  with  QPSK  modulation  and 
raised  cosine  filtering  is  50  kbps.  Each  TDMA  slot  has  length  8.29  ms  in  a  90  ms  frame. 


41 


The  supported  vocoder  information  bit  rate  is  2,400  bps  for  digital  voice,  fax,  and  data. 
The  total  information  bit  rate,  with  rate  3/4  forward  error  correction  (FEC)  coding,  is 
3,450  bps.  The  bit  error  ratio  (BER)  at  threshold  is  nominally  0.01  but  is  much  better  99 
percent  of  the  time  [Bro96]. 

The  vocoder  used  by  the  Iridium  system  converts  the  analog  (voice)  signal  to  digital 
one  using  pulse  code  modulation  (PCM)  with  a  nominal  data  rate  of  64  kbps.  The 
vocoder  transmits  a  set  of  parameters  that  emulate  speech  patterns,  vowel  sounds,  and 
acoustic  level.  The  resulting  bit  rate  of  2.4  kbps  is  thus  capable  of  transmitting  clear, 
intelligible  speech  comparable  to  the  performance  of  high  quality  terrestrial  cellular 
telephones,  but  not  quite  the  quality  of  standard  telephones  [Nel98]. 

Communications 

All  these  components  combine  together  to  give  the  user  the  ability  to  receive  and 
sender  personal  communications  worldwide  using  a  single  telephone  number.  It  is 
designed  to  augment  the  existing  terrestrial  and  cellular  telephone  networks,  not  to 
replace  them.  In  areas  where  Iridium  has  agreements  with  the  local  cellular  telephone 
provider,  and  the  user  has  a  dual-mode  handset,  communications  will  be  through  the 
terrestrial  cellular  network  instead  of  Iridium. 

The  user  dials  a  telephone  number  with  the  handset  using  an  international  13  digit 
number.  The  user  presses  the  "send"  button  to  access  the  nearest  satellite.  The  system 
identifies  the  user's  position  and  authenticates  the  handset  at  the  nearest  gateway  with  the 
home  location  register  (HLR).  Once  the  user  is  validated,  the  call  is  sent  to  the  satellite. 
The  call  is  routed  through  the  constellation  and  drops  to  the  gateway  closest  to  the 
destination.  There  it  is  completed  over  standard  terrestrial  circuits.  For  a  call  from  the 
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PSTN  to  a  mobile  user,  the  process  is  reversed.  After  the  call  is  placed,  the  system 
identifies  the  recipient's  location  and  the  handset  rings,  no  matter  where  the  user  is  on  the 
earth.  It  is  projected  that  about  95  percent  of  the  traffic  will  be  between  a  mobile  handset 
and  a  telephone  at  a  fixed  location.  The  remaining  5  percent  of  the  traffic  represents  calls 
placed  from  one  handset  to  another  handset  anywhere  in  the  world. 

Communications  between  a  satellite  and  the  mobile  user  occurs  once  a  minimum 
elevation  angle  of  8.2  degrees  is  reached.  This  angle  is  a  compromise  between  cost  and 
reception  quality.  The  higher  the  satellite  is  in  the  sky,  (i.e.  the  higher  the  elevation 
angle)  the  less  atmosphere  the  signal  must  travel  through,  and  better  the  quality.  The 
lower  the  elevation  angle  the  larger  the  satellite's  coverage  area,  and  the  fewer  satellites 
required  to  provide  worldwide  coverage. 

According  to  the  literature,  the  signal  strength  has  a  nominal  16  dB  link  margin.  This 
margin  is  robust  enough  for  users  in  exterior  urban  environments,  but  is  not  sufficient  to 
penetrate  buildings.  Mobile  users  have  to  stand  near  windows  or  go  outside  to  place  a 
call.  Handover  from  cell  to  cell  within  the  field  of  view  of  an  orbiting  satellite  is 
imperceptible.  Handover  from  satellite  to  satellite  every  nine  minutes  may  occasionally 
be  detectable  by  a  quarter-second  gap. 

Inter-Satellite  Links 

Iridium  maintains  up  to  4  ISLs  on  each  satellite.  The  ISL  are  links  established 
between  satellites  in  the  plane  (intra-planar)  and  between  satellites  in  adjacent  planes 
(inter-planar).  In  the  intra-planar  links  are  maintained  permanently,  with  each  satellite 
having  forward  and  aft  connectivity  with  the  satellites  directly  in  front  and  behind.  Inter- 
planar  links  are  dynamically  established  and  terminated  as  the  satellite  transcends  its 
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orbital  path.  Except  for  the  satellites  in  counter-rotating  planes  one  and  six,  each  satellite 
has  four  ISLs.  The  satellites  located  within  planes  one  and  six  maintain  only  three  ISLs 
each,  two  of  which  are  intra-planar.  Satellites  in  these  planes  are  not  allowed  to  establish 
ISL  between  each  other  doe  to  the  rapid  angular  change  that  occurs  between  satellites  in 
counter-rotating  planes 

The  ISLs  operate  in  the  frequency  range  of  23.18  to  23.38  GHz  at  25Mbps.  The 
horizontal  pointing  angle  between  two  satellites  in  adjacent  orbital  planes,  using  a 
reference  of  zero  degrees  parallel  to  the  equator,  varies  between  approximately  ±65 
degrees  over  one  orbital  period.  This  angle  varies  most  slowly  over  the  equator  where 
satellites  in  adjacent  orbits  are  the  most  separated,  and  it  varies  most  rapidly  over  the 
poles  where  the  orbits  cross  over  the  poles.  The  variation  in  horizontal  azimuth  between 
satellites  makes  steerable  antennae  necessary  to  maintain  inter-orbital  links.  Even  with 
steerable  antennas,  it  would  be  very  difficult  to  maintain  inter-orbital  links  between 
orbital  planes  one  and  six  at  the  higher  latitudes  where  the  azimuth  varies  rapidly.  An 
approach  used  to  maintain  inter-orbital  links  is  to  select  a  nominal  horizontal  azimuth 
close  to  that  between  satellites  over  the  equator.  Then  the  antenna  is  designed  to  be 
steerable  over  a  range  that  allows  inter-orbital  links  at  lower  latitudes  where  the 
horizontal  azimuth  changes  more  slowly.  Nominal  horizontal  azimuth  of  ±45  to  50 
degrees  with  an  antenna  steerable  over  a  30  to  45  degree  range  is  sufficient  to  maintain 
inter-orbital  links  between  latitudes  of  50  to  60  degrees  north  and  south. 
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2.7.  Summary 

The  location  management  strategies  used  in  current  and  future  satellite  systems  are 
not  discussed  in  open  literature  sources,  so  comparison  of  the  strategies  is  impossible. 
But  satellite  systems  have  the  same  type  of  location  management  needs  that  are  present  in 
cellular  phone  networks.  Information  on  these  location  management  systems  are 
available  and  can  be  adapted  for  use  in  a  satellite  environment.  Knowledge  of  cell 
networks  and  satellite  constellations  can  be  used  to  make  a  good  working  model  of  the 
typical  satellite  location  management  system.  By  doing  so,  strategies  for  optimizing 
location  update  and  paging  costs  can  be  investigated. 
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Chapter  3:  ANALYSIS  AND  MODELING  METHODOLOGIES 


"Do  not  believe  in  anything  simply  because  you  have  heard  it.  Do  not  believe  in  anything 
simply  because  it  is  spoken  and  rumored  by  many.  Do  not  believe  in  anything  simply 
because  it  is  found  written  in  your  religious  books.  Do  not  believe  in  anything  merely  on 
the  authority  of  your  teachers  and  elders.  Do  not  believe  in  traditions  because  they  have 
been  handed  down  for  many  generations.  But  after  observation  and  analysis,  when  you 
find  that  anything  agrees  with  reason  and  is  conducive  to  the  good  and  benefit  of  one  and 
all,  then  accept  it  and  live  up  to  it." 

Buddha  (C.563-C.483  B.C) 

3.1.  Introduction 

This  chapter  explains  the  methodology  used  to  analyze  the  overhead  associated  with 
modified  mobility  management  protocols  in  three  different  mobile  management 
topologies  using  three  different  traffic  patterns.  Section  3.2  starts  by  reintroducing  the 
problem  being  analyzed.  Section  3.3  continues  with  a  discussion  of  the  possible  methods 
that  can  be  used  to  analyze  the  problem,  and  explains  why  simulation  as  the  best  choice 
for  this  problem.  Section  3.4  presents  the  software  and  hardware  environment  used  to 
develop  the  simulation  models. 

With  the  general  methodology  explained,  Section  3.5  addresses  the  scope  of  the 
problem  and  how  the  complexity  of  the  model  can  be  reduced  without  affecting  the 
accuracy.  Section  3.6  extends  the  discussion  by  adding  simplifications  to  the  model  with 
a  slight  loss  of  accuracy.  With  the  problem  clearly  defined  and  scoped,  the  input  factors 
are  introduced  in  Section  3.7,  and  foster  a  better  understanding  of  how  modifications  to 
the  initial  environment  produces  the  expected  results.  Simulation  scaling,  or  reducing  the 
computational  intensity  of  the  problem,  is  introduced  in  Section  3.9  to  provide  a  way  to 
produce  accurate  data  in  minimal  time.  Section  3.8  takes  the  scoped  and  simplified 
problem  and  explains  the  working  models  developed  to  produce  the  data.  Section  3.10 
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categorizes  the  performance  metrics  produced  by  the  models  and  how  they  are  used  to 
analyze  the  results  produced  by  the  simulation.  Finally,  Section  3.11  closes  out  the 
chapter  with  a  short  explanation  of  how  the  model  are  validated  and  verified. 

3.2.  The  Problem 

Before  discussing  the  methodology  involved  in  analyzing  the  problem  and  deriving 
potential  results,  it  would  be  wise  to  restate  die  problem  being  examined. 

3.2.1.  Problem  Domain 

A  review  of  currently  published  and  on-line  literature  reveals  a  dearth  of  specific 
information  on  present  generation  of  Low  Earth  Orbiting  (LEO)  satellite  communication 
systems.  Most  of  the  information  available  is  either  outdated  facts  from  the  satellite 
system's  public  affairs  office,  or  derived  conclusions  from  academic  papers.  One  case  in 
point  is  the  complete  absence  of  published  works  on  mobility  management  protocols  used 
in  a  LEO  satellite  network.  Only  one  mention  of  call  setup  was  found,  and  it  compared 
Iridium®  to  AMPS  [Hub97].  All  research  has  concentrated  on  terrestrial  cellular 
telephone  and  personal  communication  networks. 

3.2.2.  Problem  Statement 

This  effort  determines  if  a  standard  mobility  management  protocol,  ANSI's  Interim 
Standard  for  mobility  management  (IS-41-C)  or  Global  System  for  Mobile 
communications'  (GSM)  Mobile  Application  Part  (MAP),  is  adequate  for  a  LEO  satellite 
system,  or  whether  a  satellite  specific  protocol  should  be  developed.  A  variety  of 
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changes  to  the  standard  topology  are  examined,  and  a  change  to  the  IS-41-C  protocol 
using  time-based  updating  is  introduced  and  compared  against  the  standard  protocol. 

3.2.3.  Expected  Results 

Standard  mobility  management  protocols  were  designed  for  terrestrial  cellular 
network  systems.  These  protocols  should  not  be  as  efficient  as  a  protocol  specifically 
designed  for  a  satellite  communications  network.  This  is  because  a  satellite  system  has  to 
address  a  different  set  of  problems  than  a  terrestrial  network.  These  problems  include: 

1.  LEOs  move  very  quickly  with  respect  to  the  mobile  users  they  support. 
Handoffs  due  to  the  satellite  moving  out  of  range  are  much  more  frequent  than 
handoffs  due  to  the  mobile  user  leaving  the  satellite's  footprint. 

2.  Satellites  do  not  have  a  high  speed  SONET  backbone  for  handling  mobility 
management  traffic.  Instead  satellites  support  all  control  traffic  using  organic 
resources. 

3.  LEOs  have  large  areas  of  coverage.  A  single  spot  beam  on  a  satellite 
generates  a  cell,  which  encompasses  an  area  larger  than  hundreds  of  normal  cells.  In 
Iridium,  a  single  cell  covers  318,750  kilometers.  This  "macro-cell"  needs  to  handle 
greater  number  of  mobile  users  generating  more  mobility  management  messages  than 
in  a  typical  terrestrial  cell. 

4.  In  all  operational  satellite  communication  networks,  the  traffic  management 
databases  are  located  at  the  terrestrial  gateways.  So,  to  access  any  routing, 
authentication,  or  location  information,  the  satellite  must  first  establish 
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communications  with  a  ground  station.  This  station  may  be  located  thousands  of 
miles  away,  and  require  several  satellite  hops  to  reach. 

3.3.  Method  of  Analysis 

According  to  [Jai91],  there  are  three  possible  ways  to  analyze  a  problem.  An  actual 
system  can  be  created  and  directly  measured;  a  theoretical  model  can  be  proposed  and 
analyzed  mathematically;  or  a  computer  model  can  be  built  and  the  problem  simulated. 

Direct  measurement  is  not  practical  since  access  to  and  the  ability  to  change  the 
mobility  management  protocols  of  an  operational  satellite  communications  network  is  not 
available.  In  addition,  the  actual  mobility  management  protocol  used  may  be  proprietary 
and  not  in  open  literature. 

Analytical  modeling  is  used  to  help  validate  the  findings  of  this  research  but  cannot 
be  used  to  thoroughly  analyze  the  problem.  The  research  involves  a  LEO  satellite  system 
with  a  dynamic  architecture  containing  a  large  number  of  nodes  and  queues.  While 
analyzing  a  single  node  is  practical  given  certain  simplifying  assumptions,  scaling  that 
analysis  to  a  large  network  of  nodes  requires  including  additional  assumptions.  These 
new  assumptions  negatively  impact  the  accuracy  of  the  results.  Through  analysis,  results 
acquired  are  only  accurate  within  an  order  of  magnitude,  and  this  may  not  be  specific 
enough  to  convincingly  validate  the  thesis  proposal. 

Therefore,  for  this  research,  simulation  is  most  appropriate  tool  to  use.  Current 
computer  simulation  software  and  hardware  can  handle  both  the  large  number  of  nodes 
involved  and  the  dynamic  nature  of  the  architecture.  Also,  simulations  provide  a  good 
check  on  the  proposed  hypothesis  by  limiting  the  researcher's  bias  in  constructing  the 
problem.  The  researcher  determines  the  inputs  and  develops  the  algorithms;  but  the 
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results  are  automatically  generated.  Unfortunately,  detailed  simulations  still  demand  high 
levels  of  performance  from  the  hardware  platform  and  software  tools.  The  current 
generation  of  computers  cannot  handle  a  completely  accurate  model  within  a  reasonable 
amount  of  time,  so  models  must  be  created  with  certain  assumptions  and  simplifications. 
These  simplifications  are  usually  minor  enough  that  they  don't  significantly  alter  the 
output  and  the  simulation  still  generates  better  results  than  an  analytical  model.  The 
assumptions  and  simplifications  made  are  discussed  in  Sections  3.5  and  3.6. 

3.4.  Operating  Environment 

The  simulation  is  developed  in  two  stages  on  two  different  computer  platforms.  In 
the  first  stage,  a  LEO  constellation  is  developed  using  Analytical  Graphics'  Satellite  Tool 
Kit®  (STK® )  [STKOO]  version  4.01  on  a  Micron®  ClientPro  200  with  64  MB  of 
memory.  STK®  was  chosen  because  it  provided  an  analytical  engine  to  calculate 
telemetry  and  display  multiple  2D  maps  to  visualize  various  time-dependent  information 
for  satellites.  Using  the  up-to-date  satellite  database  provided  with  the  tool,  it  is  easy  to 
generate  the  position,  altitude,  acquisition  times,  and  communication  coverage  for  the 
satellites  in  any  operational  constellation.  This  information  is  then  exported  into  a  file 
format  that  could  be  read  into  Mil  3®'s  Optimized  Network  Engineering  Tools 
(OPNET®)  [MilOO]. 

In  the  second  stage,  the  satellite  orbit  information  is  imported  into  the  OPNET 
environment  running  on  a  Sun®  Microsystems's  Ultra  2  workstation.  OPNET  was 
selected  to  develop  and  run  the  simulation  for  four  main  reasons: 
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1 .  It  provides  seamless  integration  of  satellite  ephemeris  data  from  STK® .  After 
importing  the  data  from  STK®,  OPNET®  can  perform  simulation  runs  without 
additional  interaction  with  STK® .  This  advantage  leads  to  the  second  factor:  the 
ability  to  run  OPNET®  without  interfacing  with  another  package. 

2.  Previous  network  theses  at  AFIT  used  the  combination  of  Cadence  SATLAB 
and  Designer®.  This  required  training  in  developing  a  simulation  using  two  separate 
software  applications.  After  development,  the  simulation  required  links  between  the 
two  packages  to  run  and  generate  results.  The  interdependence  required  at  least  one 
researcher  to  develop  pilot  studies  to  determine  how  the  passing  of  data  from 
SATLAB®  to  Designer®  affected  the  run-time  performance  of  the  simulation 
[Fos98a].  Using  OPNET®  eliminates  this  concern. 

3.  OPNET®  is  the  standard  simulation  tool  used  by  the  Department  of  Defense 
(DoD)  for  creating  network  simulations.  This  made  the  software  available  for 
research  on  this  thesis.  It  also  allows  the  models  developed  at  AFIT  to  be 
incorporated  in  an  overarching  DoD  Network  simulation  system  called  NETWARS. 
Therefore,  thesis  work  can  be  applied  to  real-world  problems,  and  produce  results  that 
are  immediately  available  to  DoD  units. 

4.  OPNET®  is  a  sophisticated  workstation-based  environment  for  the  modeling  and 
simulation  of  communication  systems,  protocols,  and  networks  [Opn97].  Using  a 
state-transition  paradigm,  models  of  communication  systems,  protocols  and  networks 
can  be  constructed,  executed  and  analyzed.  With  currently  available  workstations,  a 
fairly  sophisticated  model  can  be  run  within  a  reasonable  amount  of  time. 
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3.5.  Scope  of  Problem 

When  developing  the  scope  of  a  problem,  two  major  concerns  had  to  be  considered: 
accuracy  and  tractability.  First  and  foremost,  the  simulation  must  accurately  model  the 
communications  system  under  study.  The  simulation  must  accurately  model  the  behavior 
under  review  and  generate  meaningful  results.  Usually,  the  finer  the  detail  and  greater 
the  complexity  of  the  model,  the  closer  it  represents  the  real  world  system  being  modeled. 

On  the  other  hand,  time  and  computing  resources  are  limited,  and  the  model  must  be 
developed  and  run  within  these  limited  resources.  To  this  end,  simplifications  need  to  be 
made.  The  scope  of  this  problem  is  limited  to  represent  the  Iridium®  system  within  time 
and  computing  resources  available.  The  selection  of  the  Iridium®  constellation  is 
discussed  in  Section  3.6.1.  This  constraint  has  led  to  evaluating  all  facets  of  Iridium®  and 
eliminating  the  factors  that  do  not  impact  the  key  areas  of  concern. 

Since  the  main  emphasis  of  this  effort  is  examining  the  overhead  caused  by  the 
various  mobility  management  topologies,  specifically  interactions  between  the  home 
location  register  (HLR),  visitor  location  register  (VLR),  authentication  center  (AC)  and 
the  mobile  switching  center  (MSC).  With  this  in  mind,  equipment  failures,  error 
correction  and  detection,  SS7  routing,  intersystem  handoffs,  subscriber  mobility,  and 
beam  modeling  were  judged  to  not  significantly  affect  mobility  management  and  were 
not  modeled.  The  reasons  for  eliminating  these  areas  are  discussed  in  the  following 
subsections. 
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3.5.1.  Equipment  Failures 

All  networks  experience  equipment  failures,  and  a  robust  communication  protocol 
needs  to  handle  unexpected  outages.  These  physical  failures  only  affect  the  data  link  and 
network  layer  protocols  in  the  standard  OSI  Reference  Model.  All  higher  layer  protocols 
are  not  impacted  by  equipment  failures,  unless  the  failures  are  so  catastrophic  that  the 
network  layer  cannot  provide  connectivity  [Tan96].  Mobility  management  protocols  are 
generally  located  on  the  seventh  layer  of  the  reference  model,  and  so  are  not  affected  by 
equipment  failures  [GaS97,  Hei99].  For  this  reason,  equipment  failures  are  not  modeled. 

3.5.2.  Error  Detection  and  Correction 

Error  detection  and  correction  is  another  integral  part  of  any  communication 
management  scheme,  but  for  this  simulation  model  all  communication  paths,  both  wired 
and  wireless,  are  assumed  to  be  error-free.  While  this  is  not  realistic  especially  on  radio 
links,  it  does  not  affect  our  simulation  results.  In  most  communication  protocols,  error 
detection  and  correction  is  handled  by  the  second  layer  of  the  OSI  Reference  Model,  the 
Data  Link  Layer  [Tan96].  The  data  link  layer  is  responsible  for  the  reliable  delivery  of 
communication  packets  or  frames  between  two  points.  Since  this  function  is  handled  at  a 
layer  below  the  mobility  management  protocol,  so  it  can  safely  be  abstracted  out. 

3.5.3.  SS7  Routing 

Iridium®  and  all  LEO  constellations  with  inter-satellite  links  (ISLs)  require  the  ability 
to  dynamically  route  packets  from  one  destination  to  another.  The  requirement  is  driven 
by  the  constantly  varying  topology  of  the  constellation.  Satellites  are  constantly 
sweeping  the  earth  surface;  changing  their  position  relative  to  other  satellites;  and 
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severing  and  reestablishing  ISLs.  All  network  functions  are  normally  performed  by  the 
System  Signaling  number  Seven  protocol  (SS7).  This  is  a  very  complex  protocol,  which 
provides  excellent  performance  objectives  with  respect  to  availability,  dependability,  and 
delay.  For  example,  any  SS7  route  set  are  not  down  for  more  than  10  minutes  per  year, 
nor  does  it  allow  more  than  one  undetected  signaling  error  in  ten  billion  [MoS90].  This 
capability  comes  at  a  high  cost  in  complexity.  Previous  simplifications  to  the  model  have 
already  eliminated  equipment  failures  and  errors,  so  the  required  performance  objectives 
of  the  satellite  can  be  met  without  the  complex  SS7  protocol.  Instead,  a  simple  dynamic 
routing  algorithm  is  used.  This  algorithm  is  discussed  in  Section  3.6.6. 

3.5.4.  Intersystem  Handoffs 

Mobility  management  is  commonly  dividing  into  four  major  functions:  intersystem 
handoff,  automatic  roaming,  authentication,  and  call  processing.  Gallagher  defines  the 
basic  intersystem  handoff  as  "a  handoff  between  two  radio  channels  that  are  controlled  by 
two  different  mobile  switching  centers"  [GaS97].  In  the  case  of  the  Iridium0  system,  this 
involves  transferring  a  call  in  progress  from  one  satellite  to  another  without  a 
communications  interruption. 

This  aspect  of  mobility  management  is  not  addressed  by  this  thesis  because  it  is 
fundamentally  different  from  the  other  aspects  of  mobility  management.  With 
intersystem  handoffs,  a  dialog  is  established  between  the  mobile  subscriber  (MS),  the 
current  satellite  supporting  the  call,  and  one  or  more  satellites  that  are  candidates  to  take 
over  support  for  the  call.  The  conversation  involves  setting  up  an  inter-satellite 
communication  link  to  facilitate  the  handoff,  having  the  gaining  satellite  provide  an  open 
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channel  for  the  MS  to  use,  and  after  a  successful  handoff,  releasing  the  MS  channel  on 
the  losing  satellite  [GaS97].  This  entire  process  is  localized  and  does  not  involve 
interaction  between  the  HLR,  VLR,  AC,  or  MSC. 

Our  research  involves  determining  the  optimal  location  of  the  visitor  location  register, 
and  bandwidth  utilization  due  to  communications  between  the  HLR,  VLR,  AC,  and 
MSC.  Intersystem  handoffs  do  not  utilize  these  assets,  and  so  can  be  ignored  in  this 
simulation. 


3.5.5.  Subscriber  Mobility 

Subscriber  mobility  is  the  primary  reason  that  cellular  and  personal  communication 
systems  have  mobility  management  systems.  Mobility  management  systems  are  also 
required  in  satellite  communication  systems,  but  due  less  to  the  subscriber  being  mobile, 
and  more  to  the  speed  that  the  satellites  are  orbiting. 

In  the  Iridium®  system,  every  satellite  completes  one  orbit  of  the  earth  every  100 
minutes  and  28  seconds  [BrR96].  With  the  circumference  of  the  Earth  being 
approximately  24,900  miles,  the  ground  speed  of  the  satellite  is  approximately  14,871 
miles  per  hour  (Equation  2). 


D, 


CircumferenceOfEarth 


ground 


(2) 


1  CompleteOneOrbit 

The  fastest  plane,  the  SR-71  Blackbird,  can  only  reach  a  speed  of  2,194  miles  per 
hour.  That  is  only  one  seventh  of  the  speed  of  the  satellite.  In  practical  terms,  a 
stationary  subscriber  averages  a  satellite  handoff  every  nine  minutes  and  6  seconds 


(Equation  3). 
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The  SR-71  can  only  reduce  or  extend  the  time  between  handoffs  by  a  maximum  of  1 
minute  and  21  seconds  (Equation  4).  Thus,  the  mobility  of  the  subscriber  is  usually 
insignificant  in  comparison  to  the  mobility  of  the  satellite,  so  mobile  subscribers  are 
considered  stationary  for  the  simulation. 
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3.5.6.  Beam  modeling 

The  final  simplification  is  to  not  model  the  48  spot  beams  present  on  each  of  the 
Iridium®  satellites.  The  spot  beams  are  the  "cells"  of  the  Iridium®  system.  Iridium®  uses 
3168  spot  beams  cover  the  Earth,  and  in  a  perfect  simulation,  each  of  these  beams  would 
be  represented.  Unfortunately,  when  spot  beams  are  included,  the  number  of  queues  and 
processors  modeled  jumps  from  66  to  3168,  causing  simulation  times  to  lengthen,  and 
memory  requirements  to  increase.  This  increase  in  computational  complexity  does  not 
provide  any  added  benefit  for  the  standard  mobility  management  models. 

Spot  beams  represent  the  link  between  the  mobile  subscriber  and  the  satellite,  and 
allow  frequencies  to  be  reused  and  permit  more  subscribers  access  to  the  network.  If 
sufficient  bandwidth  is  available  to  handle  the  specified  capacity  of  the  satellite  without 
frequency  reuse,  then  spot  beams  become  unnecessary.  Once  again,  this  facet  of  the 
Iridium®  system  can  be  abstracted  way  because  it  does  not  directly  affect  the  primary 
focus  of  the  research. 
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The  one  flaw  to  this  reasoning  is  the  issue  of  terminal  paging.  Currently,  both  IS-41- 
C  and  GSM  MAP  do  terminal  paging  over  an  entire  location  area  (LA).  This  area 
typically  contains  60  cells.  For  this  simulation,  each  satellite  and  its  spot  beams  comprise 
a  single  location  area.  With  LA  paging,  the  spot  beams  are  unnecessary.  If  further 
research  is  done  in  this  area,  and  multi-step  paging  as  described  in  [AkH95a,  AkH95b, 
GuR98]  is  used,  then  spot  beams  will  need  to  be  modeled. 

3.6.  Assumptions 

After  simplifying  the  model  by  eliminating  unneeded  functionality,  the  model  is  then 
re-evaluated  against  satellite  specifications  and  the  tradeoffs  needed  to  actually  simulate 
the  model  within  time  and  resource  constraints.  To  produce  the  highest  fidelity  model, 
actual  satellite  specifications  are  used  whenever  the  information  is  available. 
Unfortunately,  in  many  cases,  specific  data  can  not  found  in  the  available  literature.  To 
overcome  this,  assumptions  on  the  constellation  characteristics  had  to  be  derived,  and 
were  based  on  [Fos98,  Ste96,  PrR99].  In  addition  to  deriving  system  characteristics, 
some  simplifications  are  made  to  allow  the  model  to  be  created.  The  simplifications  and 
assumptions  made  are  discussed  in  the  following  subsections.  The  subsections  address 
the  reasons  in  choosing  the  LEO  constellation  used,  the  constellation's  configuration,  the 
traffic  properties,  the  simulation's  time  scale,  the  routing  algorithm  and  finally  how 
mobile-to-mobile  traffic  is  handled. 

3.6.1.  Choosing  Iridium® 

The  primary  emphasis  of  the  research  is  to  evaluate  the  overhead  generated  by 
mobility  management  in  a  global  satellite  communication  constellation.  Standard 
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geostationary  satellites  (GEO)  like  Milstar  are  ruled  out  because  by  their  characteristics. 
Orbiting  36,000  kilometers  above  the  earth,  a  single  satellite  can  cover  one  third  of  the 
earth's  surface  [Lut98].  Only  three  satellites  are  required  to  cover  the  Earth,  and  the 
inter-satellite  routing  consists  of  passing  messages  either  to  the  satellite  on  the  left  or 
right.  This  severely  limits  the  need  to  have  a  mobility  management  protocol.  In  addition, 
the  antenna  needed  to  communicate  with  a  GEO  is  too  large  to  be  easily  transportable. 
So  candidate  satellite  constellations  are  limited  to  LEOs. 

Currently,  there  are  many  LEO  systems  either  operational  or  in  the  advanced 
planning  stages.  The  front  runners  for  this  study  are  Iridium®,  Globalstar®,  and 
Teledesic®. 

Globalstar®  is  the  simplest  system  of  the  three  using  a  standard  "bent  pipe" 
communications  architecture.  It  employs  no  inter-satellite  communication  links  and 
communicates  only  with  ground  stations  within  its  coverage  area  [Cro99].  This  type  of 
system  is  just  an  extension  of  the  terrestrial  system  and  does  not  use  mobility 
management  protocols  on  the  satellite.  The  satellite  simply  routes  all  communications  it 
receives  from  the  mobile  users  to  the  MSC  within  its  coverage  area.  These  factors 
eliminated  it  from  consideration. 

Teledesic®  and  Iridium®  both  have  inter-satellite  links  and  have  the  ability  to  route 
calls  from  one  side  of  the  globe  to  the  other.  The  difference  is  the  type  of  user  they  are 
designed  to  handle.  Teledesic®  is  designed  to  create  an  Internet  in  the  Sky,  and  will 
provide  high-speed  communications  to  service  providers  at  fixed  ground  stations 
connected  to  the  public  switched  telephone  network  (PSTN).  With  few  mobile 
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subscribers,  and  most  at  known  locations,  the  system  has  little  need  for  a  robust  mobile 
management  system  and  is  eliminated  from  consideration. 

Therefore,  the  Iridium®  constellation  was  chosen  to  represent  the  constellation  in  this 
research.  It  has  ISLs  and  is  designed  to  support  thousands  of  mobile  users.  It  is  also  one 
of  the  best-documented  satellite  constellations  currently  available. 


3.6.2.  Traffic  Properties 

All  data  within  an  OPNET  simulation  are  passed  as  packets.  The  size,  structure,  and 
distribution  of  the  packets  can  be  quickly  and  easily  configured. 


3.6.2. 1  Packet  size  and  structure 


Fossa  [Fos98a]  calculated  the  size  for  a  packet  passing  from  a  mobile  subscriber  to  an 
Iridium®  satellite  as  432  bits  since  a  voice  packet  fills  one  uplink  TDMA  slot.  Since 
then,  the  TDMA  frame  length  is  published  as  90  ms  and  the  sustained  data  rate  has  been 
reduced  to  2,400  bps  [Nel98],  so  the  number  of  bits  is  216  (Equation  5). 


2,400 bpsl 


90  ms 


1000 ms /s 


=  2 1 6bits 


(5) 


3. 6.2. 2  Distribution  of  Incoming  Calls 

This  model  assumes  that  only  voice  traffic  is  being  transmitted.  Call  interarrivals  are 

modeled  using  an  M/M/1  queue.  Calls  are  assumed  to  arrive  according  to  a  Poisson 

distribution  [A1190],  With  the  bandwidth  available  for  user  communications  reduced  to 

5.15  MHz,  the  number  of  users  supported  by  a  satellite  is  now  1 ,920  (Equation  6). 

\2tehanruds{4userslchmml)4ZcemisaUdm  _  l920ugers ,  satdUte  (6) 
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Each  user  can  send  a  packet  every  90  ms,  so  the  maximum  packet  arrival  rate  within  a 
satellite  footprint  is  21,333  packets  per  second  (Equation  7).  The  packet  arrival  rate 
includes  the  traffic  generated  by  the  users  and  the  network  management  operations. 

\910users<Xpack#luser)  1000ms ~j_  , ,  >mpackets /ssx  (7) 

90ms  lsec 

3.6.3.  Constellation  Configuration 


The  Iridium®  constellation  system  is  shown  in  Figure  10.  It  consists  of  66  satellites 
and  12  terrestrial  gateways.  The  specifications  for  system  components  are  described  in 
the  following  subsections. 


Figure  10.  Iridium®  Constellation  with  Gateways 


3.6.3. 1  Satellites 


The  satellites  are  arranged  in  six  orbits  with  1 1  satellites  plus  spares  in  each  orbit. 
For  the  simulation,  only  the  66  primary  satellites  are  modeled.  The  spare  satellites  are 
not  needed  since  equipment  failures  are  not  a  consideration.  Each  Iridium®  satellite  can 
have  up  to  four  ISLs.  The  ISLs  are  established  with  the  adjacent  satellites  and  creates  a 
Walker  Delta  Network  [Ste96].  Figure  1 1  shows  the  two  different  types  of  links  that  can 
be  established:  intra-planar  links  (light)  and  inter-planar  links  (black). 

Satellites  always  maintain  their  two  intra-planar  links.  These  links  are  with  the 
satellites  immediately  forward  and  aft  within  the  same  orbital  plane.  These  links  are 
always  available  because  the  relative  position  between  the  three  satellites  never  changes. 
Approximately  4,000  miles  separate  these  satellites. 

Two  additional  links  can  be  established  with  the  satellites  in  the  two  adjacent  planes 
(inter-planar  links).  For  this  to  happen,  two  conditions  must  hold  before  these  links  can 
be  established: 

1 .  The  satellites  must  be  flying  between  60  degrees  North  latitude  and  60  degrees 
South  latitude.  Once  a  satellite  leaves  this  region  and  travels  into  the  polar  regions, 
the  relative  position  between  the  inter-planar  satellites  changes  too  quickly  for  the 
ISL  antennas  to  maintain  a  good  connection  [Fos98a].  The  links  are  automatically 
severed. 

2.  No  inter-planar  ISL  can  be  established  between  satellites  in  the  first  and  sixth 
orbits.  Due  to  the  nature  of  the  orbits,  the  first  and  sixth  orbits  are  always  moving  in 
opposite  directions.  This  is  known  as  counter  rotating  orbits  and  once  again,  the  rate 
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of  change  between  the  satellites  is  too  great  to  have  a  link  established  [PrR99].  This 
creates  a  seam,  which  can  only  be  crossed  by  using  intra-planar  links  over  the  poles. 
Communications  over  the  ISLs  has  a  data  rate  of  25  Mbps.  No  information  is 
available  on  if  the  inter-satellite  links  are  partitioned  into  separate  channels.  It  seems  that 
they  are  divided  for  two  reasons.  First,  Iridium®  uses  a  GMS  type  protocol  that  supports 
out  of  channel  signaling  [Hub97].  Out  of  channel  signaling  requires  dedicated  channels 
for  sending  handoff,  connection,  and  automatic  roaming  messages.  Secondly,  the  ISLs 
must  route  packets  generated  from  the  mobile  subscribers.  The  communication  links 
between  the  mobile  subscriber  and  a  satellite  consist  of  a  combination  of  time  division 
multiple  access  and  frequency  division  multiple  access.  These  links  generate  a  stream  of 
216  bits  long  packets.  The  best  way  to  handle  these  packet  streams  is  to  establish 
channels  to  handle  same  type  of  packets  within  the  ISLs.  For  the  purposes  of  the 
simulation,  the  ISLs  have  been  simplified  to  being  a  single  25  Mbps  channel. 
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3. 6. 3. 2  Gateways 


Currently,  the  Iridium®  system  uses  12  Gateways  to  connect  with  the  PSTN.  The 
gateway  locations  are  listed  in  Table  2.  The  gateways  can  access  a  satellite  once  the 
satellite  has  risen  8.2  degrees  above  the  horizon.  This  connection  is  maintained  until  the 
satellite  has  fallen  below  8.2  degrees  above  the  horizon.  To  simplify  the  establishment  of 
communications,  it  is  assumed  there  is  no  obstacles,  such  as  trees  or  buildings,  to  prevent 
contact  from  being  established  at  the  lowest  possible  point. 

The  communication  data  rate  between  the  gateways  and  any  overhead  satellite  is  25 
Mbps.  This  communication  bandwidth  is  divided  into  3,840  channels.  For  this  thesis, 
the  channels  are  ignored,  and  the  entire  bandwidth  is  used  as  a  single  channel. 


Table  2.  Location  of  Iridium®  Gateways 


City 

Latitude 

Longitude 

Used  in 
Simulation 

Beijing,  China 

39:55N 

116.23E 

No 

Moscow,  Russia 

55:45N 

37:37E 

Yes 

Rome,  Italy 

41:52N 

12:37E 

Yes 

Bombay,  India 

18:58N 

72:50E 

Yes 

Nagano,  Japan 

35:00N 

135:46E 

Yes 

Seoul,  Korea 

37:35N 

127:03E 

No 

Jeddah,  Saudi  Arabia 

21:30N 

39:12E 

No 

Tempe,  Arizona 

33:23N 

111:55W 

Yes 

Honolulu,  HI 

21:19N 

157:48W 

Yes 

Rio  de  Janeiro,  Argentina 

22:27S 

42:43W 

No 

Taipei,  Taiwan 

25:02N 

121:38E 

No 

Bangkok,  Thailand 

13:50N 

100:24E 

NO 

3.6.4.  Mobile  Subscribers 

Mobile  subscribers  are  stationary,  as  explained  in  Section  3.5.5.  They  are  placed 
together  in  a  group  containing  between  216  to  28,800  members. 
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The  Iridium®  system  supports  up  to  86,000  active  users  worldwide  and  1,920  users 
within  the  footprint  of  one  satellite.  To  test  the  system,  a  worst  case  scenario  is  assumed. 
The  following  three  criteria  are  satisfied  when  placing  the  mobile  subscribers  into  the 


model: 


1 .  A  large  number  of  the  mobile  subscribers  are  located  together  in  the  footprint  of  a 
single  satellite  and  all  have  their  phones  on.  To  test  mobility  management,  it  is  not 
required  for  the  subscribers  to  be  placing  calls,  just  have  the  phone  on  standby  to  generate 
the  mobility  management  traffic  needed. 

2.  The  mobile  subscribers  have  different  HLRs  and  those  HLRs  are  located  the 
maximum  distance  from  the  subscribers.  This  is  normally  six  or  seven  satellite  hops 
away  and  may  require  crossing  the  seam  between  the  first  and  sixth  orbit. 

3.  Finally,  the  nearest  gateway  to  the  subscribers  is  at  least  one  satellite  hop  away. 

The  communication  data  rate  between  the  mobile  subscribers  and  the  supporting 

satellite  is  2,400  bps.  There  a  maximum  of  1,920  active  users  in  any  satellite  footprint,  so 
the  maximum  supported  rate  needed  in  4  Mbps  (Equation  8). 

1, 920user(2, 400bps  /  user)  =  4,608,000£y?s  (8) 

For  perfect  fidelity,  the  bandwidth  would  be  divided  into  48  spot  beams,  with  each 
beam  supporting  40  users.  Each  user  would  have  a  sustained  data  rate  of  2,400  bps. 
Instead,  for  this  simulation,  the  model  is  simplified  by  providing  only  one  4.6  Mbps 
ground  to  satellite  channel,  and  allowing  a  maximum  transmission  rate  of  21,333  packets 
per  second  (Equation  9). 


1,920 users 


1  packet  ( 1 000ms 
90ms  (  1  sec 


\ 


21,333  packet  /  sec 


(9) 
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The  bandwidth  used  by  the  users  is  in  the  L-band  and  is  not  the  same  frequency  used 
by  the  terrestrial  gateways.  In  this  simulation,  the  two  frequencies  are  modeled 
separately. 

3.6.5.  Simulation  Run  Time 

The  simulation  needs  to  run  long  enough  to  exercise  all  the  time  factors  in  the  various 
scenarios.  This  ensures  accurate  portrayal  of  the  fitness  for  the  different  test  cases.  The 
time  sensitive  variables  in  the  simulation  are  mobile  subscriber  handoffs  due  to  satellite 
movement,  time-based  location  update  requirements,  and  maximum  allowable  delay  of 
voice  communications. 

3.6.5. 1  Satellite  handoff 

A  satellite  in  the  Iridium®  constellation  completes  one  orbit  in  100  minutes  and  28 
seconds.  This  means  that  any  fixed  point  on  the  globe  falls  into  a  new  satellite's  footprint 
every  9  minutes  and  8  seconds.  If  the  VLRs  are  located  within  the  satellites,  they  need  to 
transfer  their  databases  to  another  satellite  every  9  minutes.  To  adequately  simulate  this 
event,  the  simulation  should  run  long  enough  to  have  each  mobile  group's  information 
transferred  at  least  three  times.  This  will  give  9  sample  points.  Therefore,  the  simulation 
runs  for  at  least  27  minutes  and  24  seconds. 

3. 6. 5. 2  Time-based  location  update 

IS-41-C  has  a  time-based  periodic  location  update  to  ensure  that  a  mobile  subscriber 
is  still  on  and  residing  within  the  satellite  footprint.  The  MSC  defines  the  length  of  the 
time  interval  for  location  updating.  The  typical  range  is  between  ten  minutes  and  one 
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hour  [GaS97].  For  this  simulation,  two  different  times  are  used.  In  the  first  and  second 
test  cases  in  each  scenario,  the  periodic  location  update  occurs  ten  minutes  after  the  last 
location  update.  A  periodic  location  update  is  generated  after  waiting  a  specified  amount 
of  time  since  the  subscriber  experienced  a  hand-over,  finishes  a  call,  or  sent  the  last 
update.  In  the  third  test  case,  20  minutes  passes  between  periodic  updates. 

For  the  time-based  protocol  being  introduced  in  this  thesis,  the  interval  is  exactly  the 
same  as  the  time  it  takes  for  a  satellite  to  pass  overhead:  9  minutes  and  8  seconds.  The 
minimum  time  of  27  minutes  and  24  seconds  is  required  to  test  if  a  time-based  location 
update  protocol  can  maintain  the  satellite's  VLR  database. 

3. 6. 5. 3  Voice  communication  delay 

Another  time  constraint  is  the  delay  experienced  connecting  or  disconnecting  a 
mobile  call.  This  simulation  is  not  designed  to  accurately  calculate  the  end-to-end  delay 
experienced  when  setting  up  a  call.  This  precludes  the  need  to  consider  voice 
communication  delay. 

3.6.6.  Routing 

3.6.6. 1  Routing  Algorithm  -  Bellman-Ford 

As  mentioned  in  Section  3.5.3,  this  simulation  does  not  use  the  standard  (but 
complex)  SS7  for  routing  data  packets.  Instead,  a  simple  dynamic  routing  is  needed  to 
provide  the  routing  of  data  packets.  Two  routing  algorithms  have  been  shown  to  work 
well  in  a  LEO  environment.  These  are  extended  Bellman-Ford  and  Darting  [Pra99]. 
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Stenger  demonstrated  that  at  low  traffic  loading,  an  extended  Bellman-Ford  routing 
algorithm  provided  good  results,  if  it  converges  [Ste96].  The  other  candidate  is  Darting, 
which  Pratt  showed  provided  better  results  in  a  fully  loaded  system  [Pra99]. 

For  this  research,  an  extended  Bellman-Ford  algorithm  was  chosen  because  it  is 
easier  of  the  two  to  implement,  and  without  equipment  or  link  failures,  routing  does  not 
need  to  be  as  robust  as  SS7.  Extended  Bellman-Ford  is  an  extension  to  the  standard 
distributed  Bellman-Ford.  The  purpose  of  the  enhancement  is  to  eliminate  the  original 
algorithm's  susceptibility  to  looping  and  failure  to  converge  when  the  network  becomes 
disconnected.  When  a  change  occurs,  all  the  nodes  in  the  network  do  not  immediately 
know  of  the  change.  To  inform  others  of  the  change,  the  affected  nodes  pass  network 
update  packets  to  their  neighbor,  which  update  their  routing  table  based  on  the  new 
information,  and  then  pass  it  on  to  other  nodes  that  may  be  affected  by  the  change. 

This  flood  of  packets  is  a  weakness  in  the  algorithm  because  it  restricts  the  network 
capacity  available  for  data  packets.  This  is  not  a  concern  since  overhead  involved  in 
routing  is  not  measured  in  this  thesis. 

3. 6. 6. 2  Routing  Delay 

Fossa  determined  the  most  probable  satellite  delay  when  processing  a  packet.  He 
calculated  the  minimum  time  between  packets  is  23.44  | is,  so  the  switching  must  be  less 
than  this  (Equation  10). 

- - =  23.44 vs  (10) 

42,667 packets  /  sec 

Using  a  switching  delay  of  14  jis  allows  the  satellite  to  process  the  packets  without 
causing  a  backup  or  lost  packets  [Fos98a]. 
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3.6.7.  Mobile  Subscriber  to  Mobile  Subscriber  Communications 

Even  though  the  Iridium®  system  is  a  fully  independent  worldwide  network,  it  is 
usually  used  as  an  extension  of  the  PSTN.  The  one  exception  happens  when  an  Iridium® 
mobile  subscriber  is  outside  the  range  of  a  cellular  network  calls  another  Iridium®  mobile 
subscriber. 

In  this  case,  the  mobile  subscriber's  request  goes  to  the  satellite  and  is  forwarded  to 
the  nearest  gateway  with  a  VLR,  which  contacts  the  subscriber's  HLR.  The  HLR  then 
determines  if  the  subscriber  is  authorized  to  make  the  call.  If  approved,  the  gateway  then 
contacts  the  receiver's  HLR,  which  then  request  a  destination  number  from  the  VLR 
servicing  the  receiver.  The  HLR  returns  the  destination  number  to  the  caller's  VLR.  The 
VLR  then  places  the  call  through  the  receiver's  VLR.  The  receiver's  VLR  then  pages  the 
receiver.  If  found,  the  receiver  is  connected  with  caller. 

For  purposes  of  the  thesis,  the  assumption  is  made  that  5  percent  of  the  calls  placed 
are  between  mobile  subscriber  on  the  Iridium®  system.  The  rest  of  the  time,  a  MS  calls 
someone  within  the  PSTN.  These  values  are  based  [Nel98]. 

3.7.  Input  Factors 

After  narrowing  the  scope  of  the  problem  and  stating  the  assumptions  governing  the 
simulation,  it  is  time  to  discuss  the  input  factors  needed  to  generate  the  scenarios.  In  this 
thesis,  changing  the  location  of  various  components  involved  in  mobility  management  are 
compared.  Specifically,  the  visitor  location  register  (VLR),  and  authentication  center 
(AC)  are  moved  from  the  terrestrial  gateways  into  the  satellites.  With  the  VLR  located  in 
satellite,  three  different  VLR  updating  schemes  are  tested:  the  Home  Location  Register 
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providing  the  updates,  the  VLR  database  being  passed  from  one  satellite  to  another,  and 
finally  the  VLR  database  rebuilt  each  time  during  periodic  MS  location  updates.  These 
different  topologies  and  updating  schemes  are  then  simulated  using  three  loading  factors. 
The  first  test  case  is  on  a  fully  loaded  system.  The  second  test  case  is  run  a  moderately 
loaded  system,  and  the  third  tests  a  fully  loaded  system  using  a  different  timing  interval 
for  updating  locations  and  generating  calls. 

Table  3  shows  the  combination  of  factors  that  are  tested  during  the  1 5  simulation  runs 
used  in  this  research.  That  is  followed  by  seven  subsections,  which  explain  how  each 
factor  is  determined. 


Table  3.  Input  Factors  Combination  Table 


mm 

Calls  per 

Hour 

VLR 

Location 

AC 

Location 

VLR  Update 

1 

24,672 

Gateway 

Gateway 

HLR 

2 

■ 

24,672 

Satellite 

Gateway 

HLR 

3 

12,336 

24,672 

Satellite 

Satellite 

HLR 

4 

12,336 

24,672 

Satellite 

Satellite 

DB  Transfer 

5 

12,336 

24,672 

Satellite 

Satellite 

DB  Discard 

6 

6,168 

24,672 

Gateway 

Gateway 

HLR 

7 

6,168 

24,672 

Satellite 

Gateway 

HLR 

8 

6,168 

24,672 

Satellite 

Satellite 

HLR 

9 

6,168 

24,672 

Satellite 

Satellite 

DB  Transfer 

6,168 

24,672 

Satellite 

Satellite 

DB  Discard 

11 

12,336 

49,344 

Gateway 

Gateway 

HLR 

12 

12,336 

49,344 

Satellite 

Gateway 

HLR 

13 

12,336 

49,344 

Satellite 

Satellite 

HLR 

14 

12,336 

49,344 

Satellite 

Satellite 

DB  Transfer 

15 

12,336 

49,344 

Satellite 

Satellite 

DB  Discard 

3.7.1.  Traffic  Loading 

The  first  factor  to  consider,  is  the  number  of  subscribers  needed  in  the  scenarios  to 
simulate  full  and  moderate  loading.  The  Iridium®  system  is  designed  to  support  mobile 
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subscribers,  much  like  a  cellular  telephone  system.  Assuming  that  Iridium®  strives  for 
the  same  "grade  of  service"  (GOS)  as  AMPS,  it  is  designed  for  a  GOS  of  2  percent 
blocking  [Rap96].  This  implies  that  during  the  busiest  time  of  day,  only  2  out  of  100 
calls  are  blocked  because  no  channel  is  available. 

Based  on  typical  cellular  use,  a  typical  user  generates  calls  averaging  about  three 
minutes  in  length,  and  does  not  send  or  receive  more  than  two  calls  in  an  hour.  This 
means  each  user  generates  a  traffic  intensity  of  0. 1  using  Equation  1 1 ,  where  [I  is  the 
average  number  of  call  requests  per  hours,  and  H  is  the  average  duration  of  a  call,  giving 
the  user 's  traffic  intensity  Aw  . 

4,=n#  oi) 

Au  =  ( Icalls /  hr)2>mml  call  =  0.1 

A  Iridium®  satellite  has  48  spot  beams  with  each  beam  supporting  40  channels.  The 
number  of  subscribers  that  a  single  beam  can  support  can  be  found  using  the  Erlang  B 
(blocked  calls  cleared)  formula  (Equation  12),  where  A  represents  the  user's  traffic 
intensity  and  C  is  the  number  of  channels  available.  The  results  indicate  that  a  beam  can 
support  257  subscribers.  Therefore  one  Iridium®  satellite  can  support  12,336  users. 

Pr  [blocking]  =  GOS  =  (^) 

l  k\ 

For  the  simulations  in  this  thesis,  a  fully  loaded  satellite  has  13,104  active  subscribers 
in  its  footprint.  A  moderately  loaded  satellite  has  6,552  users.  The  final  traffic  loading 
configuration  changes  the  ratio  of  location  updates  to  call  placed.  In  the  first  two  series, 
periodic  location  updates  happen  every  10  minutes,  and  calls  are  placed  once  every  half 
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hour.  In  the  third  test  case,  periodic  location  updates  occur  less  frequently,  once  every  20 
minutes,  while  call  generation  increases  to  one  every  15  minutes. 

3.7.2.  PSTN  Call  Generation 

With  the  number  of  mobile  subscriber  determined  for  each  of  the  scenarios,  it  is  a 
simple  matter  to  calculate  the  number  of  calls  that  are  generated  by  the  PSTN.  The  GOS 
is  based  on  two  calls  every  hour  for  each  of  the  subscribers.  According  the  1999  Hart 
survey,  Dynamics  and  Trends  in  the  Wireless  Marketplace,  fifty  percent  of  cellular  phone 
usage  is  for  outgoing  calls;  the  other  fifty  is  for  incoming  calls.  Based  on  these 
assumptions,  every  mobile  subscriber  is  likely  to  place  one  call  and  receive  one  call  per 
hour. 

During  the  high  load  scenario,  this  requires  the  PSTN  to  generate  1,920  calls  per  hour 
to  each  of  the  mobile  subscriber  groups.  Since  there  are  three  groups  in  each  scenario, 
and  there  are  six  PSTN  gateways,  the  total  number  of  calls  each  PSTN  gateway  needs  to 
make  is  16  calls  per  minute  (Equation  13). 

(13) 

During  the  low  load  scenario,  the  number  is  reduced  to  8  calls  per  minute. 

3.7.3.  Location  of  the  VLR 

Iridium®  has  only  12  gateways  throughout  the  world.  These  gateways  control  all 
mobility  management  aspects  for  the  Iridium®  system.  This  presents  a  potential 
bottleneck  during  heavy  usage.  The  problem  is  aggravated  by  the  location  of  the 
gateways  near  major  population  centers.  This  could  lead  to  limited  bandwidth  for 


\,920calls  /  group  /  hr(3MSGroups)  ,,  „  .  . 

— - 2 -  =  1 6calls  /  mm 

6PSTNStations{60  min/  hr) 
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handling  both  control  signals  and  calls.  Two  different  locations  for  the  VLR  are  tested: 
terrestrial  and  satellite. 

3.7.3. 1  Terrestrial 

Presently,  the  VLRs  are  located  at  the  12  gateways.  This  means  that  on  average  each 
VLR  must  service  six  satellites,  and  could  present  a  potential  bottleneck.  Metrics  on  the 
number  of  bits  sent  and  received  by  the  gateways  are  collected  to  see  if  this  is  the  case. 

3. 7.3.2  Satellite 

Placing  the  VLR  in  the  satellite  should  localize  some  of  the  mobility  management 
traffic  to  the  satellites  supporting  the  mobile  subscribers.  Specifically,  periodic  location 
updates,  VLR  lookup,  and  call  setup  between  two  subscribers  on  the  same  satellite  are 
reduced  to  one  hop.  A  possible  disadvantage  is  the  need  to  transfer  the  entire  contents  of 
the  VLR  database  to  next  satellite  during  satellite  handoff. 

3.7.4.  Location  of  the  Authentication  Center 

The  Authentication  Center  (AC)  is  almost  always  collocated  with  the  HLR  because  it 
must  be  a  very  secure  system.  It  is  used  to  prevent  fraudulent  access  to  the  cellular 
network.  This  security  is  provided  by  maintaining  a  set  of  A-keys  for  all  legitimate 
mobile  equipment.  This  key  is  known  only  by  the  AC  and  the  equipment  itself,  and  is 
never  divulged  over  the  air.  If  the  keys  are  compromised  then  the  network  would  be 
without  security. 
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Like  the  VLR,  the  AC  is  located  within  the  terrestrial  gateways.  This  presents  a 
potential  bottleneck  during  heavy  usage.  In  the  thesis  scenarios,  two  different  locations 
for  the  AC  are  tested:  terrestrial  and  satellite. 

3.7.4. 1  Terrestrial 

A  conventional  cellular  telephone  network  interacts  with  and  shares  authentication 
data  within  a  heterogeneous  environment.  The  requestors  for  authentication  of  its  mobile 
subscribers  are  not  necessarily  trustworthy,  and  so  the  A-key  is  never  given.  Instead,  the 
temporary  key,  the  Secret  Shared  Data  (SSD),  is  given.  All  authentication  is  performed 
by  the  AC  collocated  with  the  HLR.  This  is  secure,  but  uses  extra  bandwidth. 

3. 7. 4. 2  Satellite 

The  Iridium®  system  is  not  constrained  by  the  problems  of  a  heterogeneous 
environment.  It  is  a  homogeneous  system  that  controls  all  communication  pathways 
between  the  system  components.  Since  the  satellites  remain  under  control  of  the  network 
at  all  times,  they  are  trustworthy  and  can  be  given  access  to  the  A-keys  of  the  mobile 
equipment.  By  placing  the  responsibility  of  authentication  in  the  satellite,  bandwidth  can 
be  saved. 

3.7.5.  Transfer  of  the  VLR  Database 

Research  in  [Lee97]  indicates  that  moving  the  VLR  to  the  satellite  would  reduce  the 
bandwidth  needed  to  support  mobility  management.  An  area  that  is  not  addressed  in  his 
thesis  is  how  to  transfer  the  information  contained  in  the  VLR  from  one  satellite  to 
another.  This  effort  compares  three  different  methods:  HLR  update,  VLR  database 
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transfer,  and  discarding  the  VLR  database  and  rebuilding  it  using  MS  location  update 
messages. 

3.7.5. 1  HLR  Update 

The  first  method  of  VLR  database  update  is  simply  the  standard  VLR  update 
provided  by  the  IS-41-C  protocol.  When  a  mobile  subscriber  enters  a  new  location  area 
(LA),  it  registers  with  the  VLR  supporting  the  LA,  which  in  turn  communicates  with  the 
subscriber's  HLR.  Subscribers  are  deregistered  when  the  HLR  sends  a  deregistration 
message. 

3. 7.5.2  Database  Transfer 

The  second  method  examined  has  the  satellite  transfer  the  content  of  its  VLR 
database  to  the  next  satellite  every  9  minutes  and  8  seconds.  To  prevent  a  loss  of  a 
subscriber  during  the  transfer,  the  satellites  maintain  a  copy  of  the  database  after  the 
transfer.  The  subscribers  are  deregistered  after  the  specific  time  interval  has  expired 
since  that  last  location  update  by  the  subscriber. 

3. 7.5.3  Database  Discard 

The  final  method  examined  uses  the  regularity  of  the  satellite  orbits,  and  the  ability  of 
the  satellites  to  steer  their  spot  beams.  Since  the  satellite  only  support  an  area  for  a 
maximum  of  9  minutes  and  8  seconds,  the  periodic  location  updates  are  exactly  that 
length  of  time. 

To  limit  the  number  of  messages  passed  between  the  VLR  and  HLR  during  location 
update,  the  Iridium®'s  steerable  spot  beams  are  used.  The  world  is  divided  into  2150 
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specific  cells.  Each  cell  is  given  a  unique  identifier.  This  number  remains  with  the 
geographic  area  it  is  assigned  to.  The  satellite  directs  its  spotbeam  to  cover  one  of  these 
cells,  and  the  beam  maintains  coverage  of  the  cell  until  the  next  satellite  is  in  position  to 
take  over  responsibility.  While  a  spot  beam  is  covering  a  cell,  it  broadcasts  the  cell 
unique  identifier.  When  a  subscriber  does  a  location  update,  it  sends  the  standard 
location  update  information  plus  the  unique  identifier  of  the  cell  it  was  in  at  the  last 
update.  If  the  identifier  sent  is  for  the  cell  the  subscriber  is  currently  in,  then  the  VLR 
handles  authentication  locally  without  passing  messages  to  the  HLR.  If  the  number  is 
different,  then  the  VLR  registers  the  subscriber  as  required  in  the  standard  protocol. 

3.8.  Model  Design 

With  the  scope  of  the  problem  down  to  a  manageable  size,  all  the  assumptions 
defined,  and  the  inputs  known,  it  is  time  to  specify  the  model.  As  mentioned  in  Section 
3.4,  this  simulation  is  created  in  two  stages.  The  first  stage  defined  the  ephemeris  data 
needed  to  plot  the  orbits  of  the  66  satellites  in  the  Iridium®  constellation.  This  task  is 
accomplished  using  STK®,  and  the  satellite  database  that  came  with  the  package.  First, 
the  66  satellites  are  constructed  in  the  six  near-polar  orbits.  The  satellites  chosen 
provided  the  most  uniform  coverage  of  the  globe.  The  ephemeris  is  then  generated  to 
include  one  full  orbit  (100  minutes  28  seconds)  for  each  satellite.  The  time  simulation 
runs  from  0001Z  to  0142Z  on  1  October  1999. 

This  time  period  was  chosen  for  three  reasons:  First,  the  full  Iridium®  constellation  is 
in  orbit.  Second,  the  six  orbital  planes  are  clearly  delineated,  and  the  satellites  within  the 
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planes  are  evenly  spaced,  and  finally  the  beginning  of  the  new  year  seemed  appropriate. 
These  orbits  are  then  loaded  into  OPNET®. 

The  bulk  of  the  simulation  design  is  completed  using  OPNET®.  OPNET®  is  a 
network  simulation  tool  that  can  generate  nodes,  paths  and  packets.  The  first  task  is  to 
generate  the  five  separate  scenarios  needed  to  represent  the  areas  of  interest  in  the  thesis. 
The  top  level  for  each  of  the  scenarios  looks  identical,  it  contains  one  application 
attribute  definition,  six  terrestrial  gateways,  three  groups  of  mobile  subscribers  and  the  66 
satellites  in  the  Iridium®  constellation.  A  picture  of  the  standard  Iridium®  network 
developed  in  OPNET  is  shown  in  Figure  12.  The  four  different  nodes  are  explained  in 
the  following  subsections. 


Figure  12.  OPNET  Model  for  Standard  Iridium®  Network 
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3.8.1.  Application  Attribute  Definition 

The  application  attribute  definition  is  a  common  OPNET  device  for  storing  globally 
available  information.  This  node  is  developed  to  serve  two  purposes:  to  provide  the 
bookkeeping  tasks  needed  to  run  the  scenario  in  a  dynamic  environment,  and  second  to 
store  a  global  database  for  HLR  lookup. 

The  application  node  contains  only  one  node,  and  is  run  only  during  initialization  and 
shutdown.  At  initialization,  it  identifies  all  the  types  of  nodes  present  in  the  system,  and 
determines  the  unique  identifiers  assigned  to  the  nodes  by  the  simulation  kernel.  These 
identifiers  are  needed  to  establish  the  routing  tables  and  HLR  database.  The  HLR 
database  is  then  populated  with  all  the  subscribers  and  assigns  them  to  a  mobile  group 
and  HLR. 

3.8.2.  Terrestrial  Gateway 

In  the  Iridium®  network,  there  are  12  terrestrial  gateways,  which  connect  to  the 
PSTN.  These  are  located  in  the  areas  specified  in  Table  2.  For  the  scenarios  run  during 
this  thesis,  only  6  of  the  gateways  are  used.  The  number  is  limited  to  guarantee  at  least 
one  satellite  hop  between  the  mobile  subscribers  and  the  nearest  terrestrial  gateway.  The 
model  developed  to  represent  the  gateway  consists  of  two  layers  of  the  OSI  model,  layer 
three  and  seven.  The  layer  three  functions  of  routing  packets  are  performed  by  the 
receiver,  transmitter  and  router  nodes.  The  mobility  management  functions  of  layer 
seven  are  performed  by  the  director  (split),  HLR,  VLR  and  PSTN  (Figure  13). 

The  receiver  and  transmitter  processes  are  standard  OPNET-provided  nodes.  The 
frequencies  are  set  to  communicate  on  the  gateway  channel  of  the  satellites.  The  input 
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and  output  streams  are  designated  as  the  first  channel  of  the  router.  No  special  adaptation 
is  required  to  incorporate  the  nodes  into  the  model. 

The  router  is  created  specifically  for  this  theses  and  controls  two  sets  of  input  and 
output  streams.  Stream  0  carries  packets  to  and  from  layer  seven  processes.  Stream  1 
sends  packet  to  and  receives  packets  from  the  rest  of  the  network.  The  router  is  very 
simple.  All  incoming  packets  from  the  network  have  their  destination  checked,  if  the 
destination  is  this  node,  then  the  packet  is  passed  to  the  transport  layer.  If  not,  the  packet 
is  destroyed.  To  route  packets  from  the  transport  layer  to  network,  the  router  doesn't  use 
a  routing  table.  Instead  it  determines  which  satellite  is  the  closest  and  send  the  packet  to 
that  satellite. 


Figure  13.  Terrestrial  Gateway  Model 
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Once  a  packet  is  passed  up  from  the  layer  three  processes,  the  director  (called  split  in 
the  diagram)  opens  the  packet  and  determines  which  of  the  three  processes  needs  to 
process  the  packet. 

The  PSTN  process  handles  the  tasks  associated  with  connecting  calls  with  the 
terrestrial  telephone  network.  In  the  model,  it  performs  four  tasks:  it  generates  calls 
according  to  a  Poisson  distribution  to  connect  with  the  mobile  subscribers  in  the  network. 
Second,  it  terminates  calls  when  requested  by  a  mobile  subscriber.  Third,  using  a 
exponential  distribution  to  determine  the  length  of  the  call  (3  minute  mean) ,  it  terminates 
calls  placed  with  Iridium®  network.  Finally,  the  PSTN  process  accepts  connections  from 
the  mobile  subscribers. 

The  HLR  in  each  gateway  is  assigned  a  specific  number  of  mobile  subscribers  at  the 
beginning  of  the  scenario.  This  number  of  subscribers  does  not  change  during  the 
scenario.  It  manages  all  the  HLR  and  AC  responsibilities  for  its  assigned  subscribers. 
The  tasks  handled  include  authentication,  MS  lookup  for  the  call  connection,  and 
registration  and  deregistration  of  users. 

The  VLR  handles  the  VLR  responsibilities  for  the  mobile  subscribers  that  are  located 
in  its  area  of  responsibility.  The  VLR  does  all  mobility  management  communications 
with  the  mobile  subscriber.  It  authenticates  the  user,  pages  the  user  when  there  are 
incoming  calls,  requests  a  communication  line  for  establishing  calls,  and  handles 
registration  and  deregistration.  Details  on  the  responsibilities  of  the  HLR  and  VLR  are 
located  in  Section  2.10. 

The  terrestrial  gateway  configuration  isn't  altered  when  generating  the  various 
scenarios.  Instead,  the  HLR  and  VLR  processes  are  modified  to  accommodate  the 
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changes  in  protocols.  In  the  second  scenario,  moving  the  VLR  to  the  satellite,  the  VLR 
in  the  gateway  no  longer  supports  mobile  subscribers  and  acts  only  as  an  MSC  for  the 
PSTN.  In  the  third  scenario,  the  authentication  functions  of  the  HLR  are  disabled,  and 
those  functions  are  handled  by  the  VLR  in  the  satellite.  There  are  no  additional  changes 
to  the  gateway  for  the  fourth  and  fifth  scenario. 

3.8.3.  Mobile  Subscriber  Node 

The  mobile  subscriber  node  represents  a  large  number  of  mobile  subscribers  located 
within  the  footprint  of  one  satellite.  The  mobile  subscriber  is  stationary,  but  it  is  able  to 
originate  calls,  provide  location  update,  authentication,  and  respond  to  terminal  paging 
using  IS-41-C  protocol  standards.  The  internal  processes  of  the  mobile  subscriber  node 
are  shown  in  Figure  14.  Like  the  terrestrial  gateway,  the  mobile  subscriber  group  model 
supports  functionality  at  two  levels  of  the  OSI  model.  Layer  three  is  handled  by  the 
receiver,  transmitter,  and  router  processes.  The  receiver  and  transmitter  processes  are 
standard  OPNET-provided  nodes.  The  frequencies  are  set  to  communicate  on  the  MS 
channel  of  the  satellites.  The  input  and  output  streams  are  designated  as  the  first  channel 
of  the  router.  No  special  adaptation  is  required  to  incorporate  the  processes  into  the 
model. 
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Figure  14.  Mobile  Subscriber  Group  Model 

The  router  is  created  specifically  for  this  thesis  and  controls  two  sets  of  input  and 
output  streams.  Stream  0  carries  packets  to  and  from  layer  seven  processes.  Stream  1 
sends  packet  to  and  receives  packets  from  the  rest  of  the  network.  The  router  is  very 
simple.  All  incoming  packets  from  the  network  have  their  destination  checked,  if  the 
destination  is  this  node,  then  the  packet  is  passed  to  the  transport  layer.  If  not,  the  packet 
is  destroyed.  To  route  packets  from  the  transport  layer  to  network,  the  router  does  not 
use  a  routing  table.  Instead,  it  determines  which  satellite  is  the  closest  and  sends  the 
packet  to  that  satellite. 

The  mobility  management  traffic  is  generated  by  and  received  by  the  MS  Group 
process.  The  process  mimics  hundreds  to  thousands  of  individual  mobile  subscribers. 
Each  subscriber  is  independent  and  performs  the  tasks  associated  with  a  Iridium  user. 
The  subscriber  can  place  a  call,  hang  up  after  completing  a  call,  send  out  a  required 
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location  update  message,  or  turn  on  and  off  the  phone.  A  database  is  used  to  maintain  the 
current  state  of  the  subscriber,  and  ensure  that  the  next  activity  is  possible. 

Two  MS  Group  processes  are  developed  for  the  thesis.  The  standard  MS  Group  uses 
standard  IS-41-C  type  communications.  In  the  fifth  scenario,  the  location  update 
message  used  by  the  MS  Group  is  modified  to  include  the  cell  identification  number. 

3.8.4.  Satellite  Nodes 

In  each  scenario  there  are  66  satellite  nodes.  A  satellite  node  is  used  to  model  the 
routing,  orbits  and  mobility  management  functions  for  a  satellite  in  the  Iridium 
constellation.  Two  distinct  process  models  are  developed  to  model  the  satellite  in  the 
five  scenarios:  the  standard  and  the  enhanced  model. 

3.8.4. 1  Standard  Satellite  Model 

The  standard  satellite  model  replicates  the  current  Iridium®  satellite  currently  in  orbit. 
The  satellite  supports  six  communication  channels.  It  has  4  ISLs  with  each  supporting  a 
25  Mbps  channel.  It  also  has  a  terrestrial  gateway  to  satellite,  and  MS  to  satellite  link 
supporting  a  12.5  Mbps  channel.  An  illustration  of  the  internal  processes  of  a  standard 
satellite  model  is  shown  in  Figure  15. 


82 


Figure  15.  The  Standard  Iridium®  Satellite  Model 

Similar  in  structure  to  the  other  two  node  models,  the  satellite  support  mobility 
management  at  two  layers  of  the  OSI  model:  level  three  and  seven.  The  layer  three 
functions  of  routing  packets  are  performed  by  the  receiver,  transmitter  and  router  nodes. 
The  mobility  management  functions  of  layer  seven  are  performed  by  the  sink. 

The  receiver  and  transmitter  processes  are  standard  OPNET-provided  nodes.  One 
receiver  and  transmitter  pair  has  been  assigned  to  each  of  the  radio  links  established  by 
the  satellite.  Any  receiver-transmitter  pair  that  cannot  be  used  because  of  the  satellite's 
location  or  position  is  disabled.  The  inter-planar  ISLs  links  are  disabled  when  the 
satellite  enters  the  polar  regions,  and  is  not  re-enabled  until  it  crosses  the  60  degree  North 
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or  60  degree  South  line.  The  inter-planar  link  between  the  first  and  sixth  orbit  is 
permanently  disabled. 

The  router  created  for  this  research  uses  an  extended  Bellman-Ford  routing  algorithm 
to  handle  all  dynamic  routing.  The  model  monitors  the  topology  of  the  constellation  and 
the  location  of  the  terrestrial  gateways  and  mobile  subscribers  by  sending  out  echo  packet 
periodically.  When  a  node  receives  an  echo  packet,  it  immediately  sends  one  in  return. 
The  sending  node,  after  receiving  the  returning  echo,  can  determine  how  far  the  echo 
destination  is  away,  and  compute  a  cost  associated  with  that  destination.  It  examines  the 
routing  table  it  keeps  internally  and  makes  modifications  to  the  table  to  reflect  the  new 
cost  derived  from  the  echo.  If  the  cost  difference  is  greater  than  a  specified  threshold,  the 
node  generates  and  sends  out  a  packet  to  all  of  its  neighbors  containing  a  complete  copy 
of  its  routing  table.  The  algorithm  is  modified  slightly  to  reduce  the  number  of  routing 
packets  sent.  Instead  of  immediately  sending  out  routing  packets  every  time  a  change 
occurs  to  the  routing  table,  the  node  waits  a  short  time,  and  collates  all  the  changes 
received  in  the  interim  and  then  sends  all  the  changes  are  once.  The  reduction  in  traffic  is 
close  to  two  orders  of  magnitude.  The  disadvantage  to  waiting  is  the  algorithm  takes 
longer  to  converge  to  a  best  solution. 

The  layer  seven  is  very  simple  in  the  standard  satellite  model,  since  the  satellite  does 
not  support  any  mobility  management  functionality.  All  mobility  management  is  handled 
by  routing  control  signals  to  the  nearest  terrestrial  gateway,  which  contains  the  VLR  and 
HLR,  and  handles  automated  roaming,  authentication,  and  call  processing.  The  only 
process  in  layer  seven  is  a  sink,  which  destroys  any  misrouted  packets. 
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3.8.4. 2  Enhanced  Satellite  Model 


The  enhanced  satellite  model  has  all  the  features  of  the  standard  satellite  model,  plus 
a  varying  amount  of  mobility  management  responsibilities.  The  mobility  management 
functions  assigned  to  the  satellite  are  handled  by  the  satellite's  VLR.  Again,  layer  three 
and  seven  are  represented  by  the  process  internal  to  the  satellite.  This  process  is  shown 
in  Figure  16.  Since  no  modification  is  made  to  layer  three,  no  discussion  is  necessary. 
Please,  refer  to  Section  3.8.4. 1  for  that  information. 


Figure  16.  The  Enhanced  Iridium®  Satellite  Model 

The  responsibilities  of  the  mobility  management  are  handled  by  the  VLR.  The  VLR 
needs  to  have  sufficient  memory  and  speed  to  handle  all  typical  mobility  management 
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traffic.  The  biggest  memory  requirement  is  for  the  VLR  database  used  to  store  the 
information  about  the  mobile  subscribers  being  supported.  The  amount  of  memory 
needed  for  database  is  simply  the  maximum  number  of  subscribers  supported  by  the  VLR 
multiplied  about  the  size  of  a  VLR  entry.  The  Iridium®  system  is  based  on  having 
approximately  10  million  user  worldwide  [Gav97].  In  a  mobility  management  scheme 
based  on  AMPS,  the  typical  VLR  entry  contains  the  MS  identification  (IMSI-15  bits, 
TMSI-15  bits),  the  HLR  identifier  (14  bits),  the  local  area  identifier  (14  bits),  information 
about  the  services  allowed  for  the  subscriber  (15  bits),  and  the  Mobile  Station  Roaming 
Number  (15  bits)  for  a  total  of  88  bits. 

To  determine  the  amount  of  memory  required  to  support  the  VLR  database,  a 
maximum  number  of  subscribers  a  satellite  can  support  needs  to  be  determined. 
Assuming  the  minimum  acceptable  grade  of  service  for  the  network  is  10%  (one  in  every 
10  calls  is  blocked),  the  maximum  users  within  a  spot  beam  is  390.  Therefore,  18,720 
users  can  be  supported  on  one  satellite.  The  VLR  database  needs  205,920  bytes  of 
memory  to  support  the  maximum  number  of  subscribers  (Equation  14).  The  speed  of  the 
processor  should  be  adequate  to  parse  through  the  typical  sized  database  in  less  than  a 
second. 

1 8,720subscribers(88bits / subscriber )  _  2Q5  kbytes  ( 1 4) 

8  bits  /  byte 

In  the  second  scenario,  the  VLR  is  exactly  like  die  VLR  developed  for  the  terrestrial 
ground  station  in  the  first  scenario.  The  only  difference  is  that  the  VLR  is  now  located  in 
the  satellite.  In  the  third  scenario,  the  VLR  is  modified  to  allow  it  to  authenticate  mobile 
subscribers  without  retrieving  an  SSD  from  the  HLR.  The  VLR  is  still  required  to  report 
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the  results  to  the  HLR.  The  fourth  scenario  supports  the  transfer  of  the  contents  of  the 
VLR  database  from  one  satellite  to  another.  When  the  VLR  recognizes  that  is  supporting 
a  new  location  area,  it  automatically  transfers  its  VLR  database  contents  to  the  satellite 
following  it  in  the  same  orbit.  The  transfer  is  accomplished  every  9  minutes  and  8 
seconds. 

The  fifth  scenario  drops  the  requirement  for  transferring  the  VLR  database.  The 
database  is  maintained  by  updating  the  MS  entry  on  a  time  basis.  If  an  MS  does  not 
make  a  check  in,  it  is  automatically  dropped  from  the  VLR  database,  but  die  HLR  is  not 
notified.  The  only  time  a  deregistration  message  is  sent  is  when  the  MS  initiates  the 
conversation  with  a  deregistration  message.  The  mobile  subscriber  sends  a  location 
update  message  every  9  minutes  and  8  seconds.  Part  of  the  location  update  message  is 
the  location  identifier  of  the  LA  during  the  last  update.  If  the  identifier  is  the  same  as  the 
current  LA,  then  the  VLR  authenticates  the  MS  but  does  not  send  an  Authorization  Status 
Report  (ASR)  to  the  HLR.  The  ASR  is  only  sent  when  the  location  identifiers  do  not 
match.  If  a  call  connection  is  passed  to  the  VLR  before  the  first  update  by  the  MS,  the 
VLR  assumes  the  MS  is  present  and  page  the  LA.  If  no  response  is  given,  the  message  to 
passed  to  previous  VLR,  if  that  is  still  unsuccessful,  the  HLR  is  informed  that  the 
subscriber  could  not  be  found. 

3.9.  Simulation  Scaling 

To  this  point  in  describing  the  model  development,  packet  generation  or  how  it 
effects  the  running  of  a  simulation  has  not  be  addressed.  Fossa  reported  that  "modeling 
the  actual  traffic  load  of  the  Iridium®  will  run  very  slowly"  [Fos98a].  As  an  example,  he 


87 


pointed  out  that  when  running  a  15  minute  simulation  between  only  two  earth  stations  at 
1 1  percent  capacity,  the  resulting  execution  cycle  took  two  to  three  weeks  to  complete. 

Using  pilot  studies  and  proper  scaling,  Fossa  demonstrated  that  accurate  results  can 
be  obtained  without  the  time  penalty  incurred  with  using  an  actual  traffic  load.  This  is 
confirmed  using  a  pilot  study  on  model  of  the  Iridium®  system  as  it  is  currently 
configured. 

In  an  OPNET®  simulation,  networks  are  modeled  as  interconnection  of  finite  state 
machines,  with  all  communication  between  processes  done  through  message  passing. 
This  is  true,  whether  the  message  is  a  data  packet,  interface  control  information,  remote 
process  activation,  interrupt,  or  other  methods.  The  transfer  of  a  single  message  is 
accomplished  by  an  event.  The  number  of  events  generated  directly  effects  the  speed  of 
the  simulation. 

Since,  this  research  examines  the  generation  and  passing  of  mobility  management 
packets,,  the  number  of  packets  created  and  passed  is  the  biggest  factor  in  the 
determining  the  length  of  each  simulation  run.  To  find  a  reasonable  time  period  for  each 
simulation  run,  a  pilot  study  is  developed  to  test  the  effect  of  scaling  the  number  of 
packet  generated. 

The  pilot  used  a  model  with  the  full  Iridium®  constellation,  six  earth  stations,  and 
three  groups  of  mobile  subscribers.  The  six  earth  stations  from  Table  1  were  chosen  and 
included  Honolulu,  Tempe,  Moscow,  Rome,  Bombay  and  Nagano.  Three  groups  of 
mobile  subscribers  are  placed  in  South  America,  Africa,  and  Australia.  Four  pilot 
simulations  are  run.  The  first  simulation  exercised  the  full  capacity  of  the  Iridium 
constellation.  It  placed  29,000  mobile  subscribers  in  each  of  the  three  groups.  Each  of 
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the  earth  stations  generated  4  calls  per  second.  The  simulation  is  run  for  548  seconds  and 
generated  356,798,602  octets  of  control  information.  The  second  simulation  reduced  the 
number  of  subscribers  by  a  factor  of  1 0  and  also  reduced  the  number  of  calls  by  the  same 
factor.  This  produced  35,380,728  octets  of  information.  The  third  simulation  again 
reduced  the  number  of  subscribers  and  calls  by  a  factor  of  10.  This  simulation  generated 
a  total  of  3,635,926  octets.  Finally,  the  last  simulation  ran  with  29  subscribers  in  each 
group,  and  each  earth  station  only  generating  one  call  every  250  seconds.  This  run  sent 
358,016  octets  of  information.  The  variance  between  the  runs  is  less  than  2  percent  (See 
Table  4).  Balancing  the  need  for  the  most  accurate  results  with  a  reasonable  length  for 
each  run,  a  scaling  factor  of  200  is  chosen.  The  simulation  runs  reduced  the  number  . 
With  a  scaling  factor  of  200,  the  simulation  ran  for  approximately  76  minutes  on  a  Sun 
Ultra  10,  instead  of  over  8  hours  for  the  unsealed  or  baseline  system. 

Table  4.  Pilot  Results 


Simulation 

Users 

Octets 

Generated 

Octets  Generated 
(Scaled) 

WWHillli 

Baseline 

29,000 

356,798,602 

356,798,602 

0.0% 

one  tenth 

2,900 

35,380,728 

353,807,280 

0.8% 

one-hundredth 

290 

3,635,926 

363,592,600 

1.8% 

one-thousandth 

29 

358,016 

358,016,000 

0.3% 

3.10.  Performance  Metrics 

This  section  discusses  the  five  performance  metrics  investigated  in  this  study:  total 
mobility  management  bytes,  total  mobility  management  packets,  total  conversations,  calls 
not  completed,  and  packets  lost. 
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3.10.1.  Total  Mobility  Management  Bytes 

The  first  metric  is  the  number  of  mobility  management  bytes  needed  to  be  support  all 
the  mobility  management  functionality  for  the  scenarios  tested.  The  count  is  generated 
through  two  operations.  First,  the  size  of  each  control  packet  is  multiplied  by  the  number 
of  hops  the  packet  transversed.  This  value  is  then  added  to  the  accumulated  total  for  the 
entire  system,  and  the  total  for  the  gateway  generating  the  signal.  The  number  derived  is 
compared  to  maximum  number  of  packets  in  the  system  to  determine  the  percentage  of 
bandwidth  devoted  to  control.  The  number  is  also  used  to  determine  the  relative 
efficiency  between  the  different  protocols. 

A 

3.10.2.  Total  Mobility  Management  Packets 

The  next  metric  is  the  number  of  mobility  management  packets  needed  to  be  support 
the  mobility  management  functionality.  The  count  is  simply  the  number  of  packets 
created  to  support  mobility  management.  This  value  is  accumulated  over  of  the  entire 
simulation  run.  The  number  is  used  to  determine  how  many  messages  are  required  to  be 
passed  to  handle  mobility  management  functionality. 

3.10.3.  Total  Conversations 

A  conversation  is  defined  as  a  series  of  messages  required  to  complete  a  single 
management  task.  Management  tasks  include  updating  the  location  of  a  mobile 
subscriber  or  establishing  a  call  between  two  customers.  The  number  of  conversations 
made  during  a  simulation  run  is  the  combination  of  three  factors:  a  random  seed 
generating  the  calls,  a  random  seed  determining  the  next  action  of  a  mobile  subscriber, 
and  the  number  of  mandatory  location  updates.  The  lower  the  number  of  conversations, 
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the  less  traffic  that  needs  to  be  generated.  The  number  is  also  used  to  determine  relative 
efficiency  between  the  different  protocols. 

3.10.4.  Calls  Not  Completed 

Another  metric  is  the  number  of  incoming  calls  that  could  not  be  completed  because 
the  receiver  could  not  be  found.  Not  counted  are  calls  that  could  not  be  completed 
because  the  receive  is  either  off  the  air,  or  busy  with  another  call.  The  value  is  used  to 
determine  if  the  protocol  is  performing  the  job  it  is  designed  for.  The  most  efficient 
algorithm  is  useless  if  the  algorithm  only  works  half  of  the  time. 

Ideally,  every  call  goes  through  the  first  time  and  with  a  minimal  amount  of  delay. 
This  metric  reflects  the  interaction  between  frequency  of  mobile  subscriber  updates,  size 
of  the  paging  area,  and  the  frequency  of  incoming  calls. 

3.10.5.  Packets  Lost 

The  final  metric  is  the  number  of  packets  lost.  Mobility  management  packets  have  to 
compete  with  short  message  signaling,  operation  and  maintenance  packets  for  space  on 
signaling  channel.  Overloading  the  system  results  in  lost  packets  due  to  buffer 
overflows.  With  the  queue  in  each  of  the  satellite  supporting  4000  packets,  the  chances 
of  packet  loss  should  be  minimal. 

3.11.  Model  Verification  and  Validation 

3.11.1.  Verification 

Verification  is  testing  the  model  to  ensure  that  it  performs  as  intended.  Model 
verification  is  completed  at  two  levels:  unit  level  and  system  level 
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3.11.1.1  Unit  Level  Testing 


At  the  unit  level,  the  simulation  model  is  viewed  as  a  composite  of  three  different 
types  of  nodes:  satellites,  gateways,  and  mobile  subscribers.  During  the  first  round  of 
testing,  each  of  the  nodes  went  through  a  complete  syntactical  check  using  OPNET  s 
built-in  verification  tools.  This  verified  that  there  are  no  grammatical  errors  in  the  code, 
all  variable  are  declared  and  properly  sized  and  formatted. 

The  second  round  involved  white  box  testing.  The  internal  algorithms  used  by  the 
nodes  are  tested.  The  testing  involved  verifying  the  entrance,  exit,  and  loop  transition  for 
each  state  transition.  This  verified  that  all  states  are  defined,  and  no  undefined  transitions 
are  present. 

The  third  round  concentrated  on  black  box  testing.  The  nodes  are  tested  in  isolation 
to  verify  the  inputs  and  outputs.  Each  input  is  examined  before  entering  the  node,  and  the 
output  variables  are  compared  with  expected  results. 

3.11.1.2  System  Level  Testing 

After  the  individual  nodes  are  verified,  then  the  interactions  between  the  nodes  are 
tested.  The  interactions  are  limited  to  two  nodes,  first  satellite  to  gateway,  then  satellite 
to  mobile  subscriber.  The  interactions  examined  the  message  passing  between  the  nodes. 
After  two  node  interactions  are  verified,  a  three  way  interaction  is  tested.  Once  again,  the 
messages  passed  are  examined. 

A  routing  test  is  then  executed,  where  a  network  of  ten  stationary  satellites  is  given 
500  msec  to  find  the  shortest  paths.  The  routing  tables  of  each  of  the  satellites  are  then 
examined  for  loops  and  other  anomalies. 
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The  final  test  is  a  step-by-step  trace  of  both  the  location  update  and  terminal  page 
involving  one  mobile  subscriber,  three  satellite  nodes  and  two  gateways.  The  mobile 
subscriber  is  attached  to  one  of  the  gateways  as  a  visiting  node,  while  the  other  gateway 
generated  traffic  for  the  MS.  The  satellites  provided  connectivity  between  the  two 
gateways. 

3.11.2.  Validation 

Formal  validation  of  a  computation  simulation  is  usually  divided  into  validating  three 
aspects  of  the  model:  the  operating  assumptions,  the  input  values,  and  the  results.  These 
areas  are  subjected  to  validity  tests  based  on  real  system  measurements,  theoretical 
solutions  or  expert  evaluation. 

3.11.2.1  Validation  of  Operating  Assumptions 

When  developing  the  model,  Iridium®  specifications  are  used  whenever  the 
information  is  available.  When  the  information  is  not  available,  the  model  relied  on  the 
assumptions  made  in  previous  theses  referenced  in  [Ste96,  Fos98,  Pra99]. 

3.11.2.2  Validation  of  Input  Values 

All  input  values  are  compared  with  values  specified  in  the  literature  about  Iridium, 
and  available  information  about  the  two  standard  protocols. 

3.11.2.3  Validation  of  Results 

For  this  simulation,  real  system  measurements  are  not  available  for  comparison,  so 
validation  is  based  on  theoretical  results  from  highly  simplified  models.  The  three  output 
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results  for  this  research  are  total  number  of  control  packets,  calls  lost,  and  number  of 
packets  lost. 

3.11.2.3.1  Control  Packet  Validation 

A  simulation  is  set  up  similar  to  the  system  trace  used  in  system  verification.  A 
system  of  two  gateways,  three  satellites  and  one  mobile  subscriber  is  constructed.  A 
location  update  sequence  is  recorded  for  each  of  the  mobility  management  protocols. 
These  traces  are  compared  with  the  traces  found  in  current  literature.  After  the  traces  are 
validated,  the  counts  reported  by  the  simulation  are  compared  to  the  theoretical  results 
derived  through  analysis. 

3.11.2.3.2  Calls  Lost 

The  system  is  set  to  request  connections  with  six  imaginary  and  four  active  mobile 
subscribers.  The  simulation  is  executed,  and  the  results  are  compared  with  the  expected 
results.  The  expected  results  are  that  at  the  initial  start  of  the  system,  calls  are  lost  until 
the  subscribers  register  with  the  HLR.  After  registration,  no  calls  should  be  lost. 

3.11.2.3.3  Number  of  Packets  Lost 

There  are  two  conditions  that  lead  to  packets  being  lost  in  the  system.  The  first 
condition  is  buffer  overflow.  This  is  tested  by  reducing  the  queue  size  in  each  of  the 
satellite  to  zero,  and  setting  the  satellite  processing  time  to  20ms.  Packets  are  then  sent  in 
a  uniform  rate  of  1  packet  every  10  ms.  The  system  outputs  are  then  compared  with  the 
expected  loss  of  half  of  the  packets  sent. 
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The  second  condition  that  leads  to  packet  loss  is  excessive  delay  on  data  packets.  If  a 
data  packets  takes  more  then  400ms  to  reach  its  destination,  it  is  dropped  from  the 
system.  A  test  is  setup  where  packets  are  routed  from  the  originating  gateway  through 
three  satellite  to  the  destination  gateway.  The  packet  generator  is  altered  to  put  a  creation 
time  on  the  packets  that  would  cause  them  to  expire  while  in  transit.  The  times  are 
predetermined  and  caused  one  fourth  of  the  packets  to  expire  while  processing  through 
the  first  satellite,  a  one  fourth  to  expire  in  the  second  satellite,  etc. 

3.12.  Summary 

This  chapter  focused  on  the  methodology  used  to  develop  a  computer  simulation  to 
evaluate  the  mobility  management  overhead  using  various  protocols  and  topologies.  The 
problem  is  first  defined  and  scoped  to  include  only  the  most  important  aspects  of  mobility 
management.  The  model  is  then  simplified  to  reduce  complexity  and  allow  the  system  to 
run  within  the  time  and  computing  constraints  of  the  environment.  The  input  factors  to 
the  problem  are  then  discussed.  The  performance  metrics  are  then  presented  and 
discussed.  This  is  followed  by  a  discussion  of  the  simulation  model,  with  a  breakdown  of 
the  different  types  of  nodes,  and  packets  used.  The  chapter  ended  with  a  discussion  of 
the  verification  and  validation  used  to  ensure  the  correctness  of  the  model. 
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Chapter  4:  Analysis 


"[Analysis]  is  where  the  answer  is  right  and  everything  is  nice  and  you  can  look  out  of  the 
window  and  see  the  blue  sky  --  or  the  answer  is  wrong  and  you  have  to  start  over  and  try 
aqain  and  see  how  it  comes  out  this  time." 

-Carl  Sandburg  (1878- 1967) 

4.1.  Introduction 

The  purpose  of  this  chapter  is  to  present  an  analysis  of  the  data  generated  from  the 
five  test  scenarios  described  in  Chapter  3.  The  chapter  begins  with  a  discussion  of  the 
statistical  accuracy  of  the  data  in  Section  4.2.  The  expected  variances  in  each  of  the 
metrics  are  also  discussed.  The  analysis  of  the  mobility  management  metrics  is  then 
presented  in  four  parts. 

In  Section  4.3,  the  first  scenario,  the  standard  IS-41-C  protocol,  is  discussed,  and  the 
three  test  cases  (low,  high,  and  modified  load)  developed  are  discussed.  Section  4.4 
presents  the  second  scenario.  It  explains  the  changes  in  topology  made.  Section  4.5 
continues  with  the  third  scenario  and  the  topological  changes  made  to  create  the  scenario. 
With  the  final  topology  in  place,  Sections  4.6  and  4.7  explain  the  fourth  and  fifth 
scenarios.  The  last  two  scenarios  introduce  two  different  methods  to  update  the  contents 
of  the  VLR  database  located  in  the  satellite. 

With  the  scenarios  explained,  the  analysis  of  the  data  begins  in  Section  4.8.  The 
analysis  of  average  hop  count,  number  of  conversations,  total  number  of  hops,  total 
number  of  message  sent,  and  total  number  of  bytes  sent  are  explained  in  the  subsections. 
The  chapter  concludes  with  a  summary  of  the  all  the  analysis  presented. 
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4.2.  Statistical  Accuracy 

Five  different  topology-protocol  test  cases  are  presented  in  this  thesis.  Each  of  the 
test  cases  is  investigated  under  three  different  traffic  loads.  In  addition,  all  scenarios  are 
run  five  times  using  a  different  random  number  generator  seed  each  time  to  guarantee 

f 

that  the  metrics  are  not  causally  effected  by  the  Poisson  traffic  generator.  A  data  set  is 
collected  for  each  of  the  runs.  The  data  set  includes  the  number  of  mobility  management 
conversations,  the  number  of  hops,  the  number  of  mobility  management  bytes,  and  the 
number  of  mobility  management  packets 

Once  all  the  data  set  are  collected,  the  results  of  the  runs  using  the  different  seeds  are 
combined  and  an  average  mean  and  standard  deviation  for  the  metric  is  calculated.  A  95 
percent  confidence  interval  is  calculated  for  each  metric  using  the  student's  t-distribution 

(Equation  15),  where  the  100(1 -a )  is  the  confidence  interval,  x  is  the  average  of  the  five 
samples,  s  is  the  average  of  the  five  sample  means,  n  is  the  number  of  sample  means,  and 
t  is  the  student's  t-distribution  [Jai91]. 

1 00(1  -a)%CI  =  x±t[\-a;n-\]s/4n  (15) 

To  determine  if  the  five  random  runs  is  sufficient  to  gain  a  90  percent  confidence 
interval  on  the  data  collected,  the  average  hop  count  is  chosen  to  compare  between  two 
scenarios.  The  average  is  collected  in  two  scenarios,  the  low  load  and  the  high  load.  If 
the  number  of  runs  is  sufficient  then  the  average  hop  count  for  the  two  scenarios  should 
be  equivalent. 

Table  5  shows  the  standard  deviations  for  the  hop  count  are  low,  with  the  highest 
deviation  be  0.1096298.  Table  6  also  shows  a  low  standard  deviation  for  all  the  scenarios 
run,  with  the  highest  deviation  of  0.1333  shown  by  the  database  transfer  scenario.  A 
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comparison  the  average  hop  count  ranges  for  each  of  the  five  scenarios  shows  that  in 
each  case  the  ranges  overlap.  From  a  purely  statistically  point  of  view,  the  ranges  for  the 
low  load  and  the  high  load  are  equivalent.  This  shows  that  five  runs  of  the  simulation 
with  different  seed  values  are  sufficient  to  produce  a  small  confidence  interval  using  the 
given  input  test  parameters.  All  the  charts  presented  in  the  rest  of  this  chapter  represent 
the  average  of  five  simulation  runs,  very  similar  to  the  information  presented  in  Table  5 
and  Table  6. 


Table  5.  Average  Hop  Count,  Low  Load 


Average  Hop 
Count 

Mean 

Standard 

Deviation 

95%  Confidence  Interval  j 

Range 

Minimum 

Maximum 

IC-41-C 

7.075 

0.0698493 

0.061224 

7.0142053 

7.1366540 

VLR  on  Satellite 

4.018 

0.1096298 

0.096093 

3.9219975 

4.1141833 

AC  on  Satellite 

2.984 

0.0773963 

0.067840 

2.9157593 

3.0514383 

Database  Transfer 

2.754 

0.0838670 

0.073511 

2.6808711 

2.8278936 

2.936 

0.0675176 

0.059181 

2.8765673 

2.9949284 

Table  6.  Average  Hop  Count,  High  Load 


Average  Hop 
Count 

Mean 

Standard 

Deviation 

95%  Confidence  Interval  | 

H9 

Minimum 

Maximum 

IC-41-C 

7.073 

0.0485987 

0.042598 

7.0306546 

7.1158502 

VLR  on  Satellite 

4.057 

0.0636733 

0.055811 

4.0013453 

4.1129674 

AC  on  Satellite 

2.965 

0.0786411 

0.068931 

2.8960432 

3.0339044 

Database  Transfer 

2.777 

0.1333093 

0.116848 

2.6601258 

2.8938228 

2.917 

0.0448915 

0.039348 

2.8776844 

2.9563810 

4.3.  Iridium®  Standard  Topology 

This  section  briefly  explains  the  test  scenarios  used  to  establish  a  baseline  using  the 
topology  currently  fielded  by  the  Iridium®  network.  In  this  topology,  all  mobility 
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management  databases  and  functions  are  located  in  the  terrestrial  gateways.  The  scenario 
is  referred  to  as  either  the  standard  scenario  or  the  IS-41-C  scenario.  As  stated 
previously,  each  of  the  test  scenarios  is  run  using  five  different  seeds  Three  test  cases  are 
run:  low  load,  high  load  and  modified  high  load. 

4.3.1.  Low  Load 

In  this  test  case,  the  number  of  subscribers  and  amount  of  traffic  generated  by  the 
PSTN  is  low  (50  percent  of  the  maximum).  The  scenario  simulates  a  network  operating 
under  minimal  load.  Each  of  the  six  terrestrial  gateways  attempts  to  place  2  calls  per 
second  to  the  mobile  subscriber.  Each  of  the  mobile  subscriber  groups  places  2  calls  per 
second,  with  90  percent  of  the  calls  going  to  the  PSTN,  and  the  other  10  percent  to  other 
mobile  subscribers. 

The  number  of  subscriber  in  each  MS  Group  is  half  the  maximum  number  that  can  be 
supported  by  a  satellite  with  a  GOS  of  2  percent.  In  this  scenario,  each  group  contained 
14,400  subscribers. 

This  test  case  is  designed  to  reflect  an  unstressed  network,  and  should  establish  a 
typical  load  generated  by  the  standard  IS-41-C  protocol.  This  is  used  as  a  basis  to  judge 
the  fitness  of  the  proposed  changes. 

4.3.2.  High  Load 

The  next  test  case  increases  the  number  of  subscribers  and  the  amount  of  traffic 
generated  by  the  PSTN  to  reflect  a  full  load  with  a  GOS  of  2  percent.  In  this  scenario, 
the  number  of  subscribers  increases  to  86,400.  The  number  of  calls  from  each  of  the 
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terrestrial  gateways  increases  to  4  calls  per  second,  and  each  MS  Group  also  generates  4 
calls  per  second. 

This  scenario  is  designed  to  reflected  the  network  during  the  busiest  hour  of  the  week. 
This  could  be  during  the  evening  rush  hour  on  a  Thursday  or  Friday.  The  number  of 
blocked  calls  should  increase  and  should  the  number  of  mobility  management  messages 
sent.  Overall,  the  mobility  management  should  increase,  but  not  double. 

4.3.3.  High  Load,  Modify  Call  and  Update  Frequency 

The  final  test  case  maintains  the  number  of  subscribers  at  a  high  level  but  the  traffic 
load  is  again  doubled.  The  number  of  calls  from  the  terrestrial  gateways  and  from  the 
MS  groups  is  now  8  calls  per  second.  In  addition,  the  frequency  of  periodic  updates  is 
decreased  from  once  every  10  minutes  to  once  every  20  minutes. 

This  scenario  determines  the  sensitivity  of  each  of  the  topologies  to  traffic  generation 
and  location  updates.  The  topologies,  which  handle  calls  in  the  shortest  number  of  hops, 
are  favored  over  the  topologies  that  do  better  with  location  updates. 

4.4.  Satellite  VLR  Topology 

This  is  the  first  modified  topology  tested.  It  is  also  the  simplest.  The  VLR  and  its 
associated  database  are  moved  from  the  terrestrial  ground  station  and  placed  into  the 
orbiting  satellites.  The  method  of  updating  remains  the  same  as  specified  in  the  IS-41-C 
standard.  The  mobile  subscribers  transmits  a  location  update  message  when  any  one  of 
the  following  occurs: 

1 .  The  subscriber  first  becomes  active. 
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2.  The  subscriber  moves  into  a  new  location  area.  For  this  scenario,  that  is  when  a 
different  satellite  supports  the  subscriber. 

3.  A  sufficient  amount  of  time  has  passed  since  the  last  update.  For  the  first  two  test 
cases,  the  periodic  update  occurs  every  ten  minutes,  and  in  third  test  case  the 
update  occurs  every  20  minutes. 

There  are  two  expected  results  from  moving  the  VLR  database  to  the  satellite.  First 
the  number  of  hops  between  the  mobile  user  and  the  VLR  is  reduced  to  one,  and  this 
reduces  the  number  of  hops  required  to  complete  any  mobility  management  conversation. 
Second,  the  number  of  location  updates  increases.  This  should  be  very  evident  in  the 
third  run.  When  the  VLR  is  located  in  the  terrestrial  gateway,  the  mobile  subscriber  most 
likely  never  leaves  the  location  area,  since  the  location  area  covers  almost  a  tenth  of  the 
Earth's  surface.  But  when  the  VLR  database  is  moved  to  the  satellite,  the  subscriber 
changes  VLR  database  every  time  a  new  satellite  comes  into  view. 

The  three  test  cases  run  with  the  Satellite  VLR  topology  are  the  same  as  described  in 
Section  4.3.  The  expected  results  are  a  reduction  in  the  number  of  hops  during 
conversations,  but  additional  conversations,  especially  in  test  case  three. 

4.5.  Satellite  AC  Topology 

The  next  scenario  retains  topological  changes  made  in  scenario  two,  and  adds  to  it. 
The  authentication  center  (AC)  is  moved  from  the  terrestrial  gateway  and  added  to  the 
VLR  in  the  satellite.  Without  modifying  the  protocols,  the  addition  of  the  AC  to  the 
satellite  causes  a  slight  decrease  in  the  number  of  hops  required  to  place  calls  in  the 
system  and  during  initial  registration  with  the  system. 
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The  three  test  cases  performed  with  the  Satellite  AC  topology  are  the  same  as 
described  in  Section  4.3.  The  expected  results  are  very  similar  message  and  location 
update  pattern  are  the  Satellite  VLR  topology  with  only  a  slight  decrease  in  hop  counts. 

4.6.  Satellite  VLR  Database  Transfer 

The  fourth  scenario  makes  the  first  major  change  to  the  protocol  provided  by  IS-41-C, 
database  transfer.  This  area  is  not  addressed  in  the  standard,  and  is  not  a  likely  scenario 
in  terrestrial  cellular  network.  It  is  a  distinct  possibility  in  a  satellite  environment.  In  this 
scenario,  every  9  minutes  and  8  seconds,  the  satellites  transfer  their  VLR  databases  to  the 
next  satellite.  The  AC  is  relatively  static  and  remains  with  the  satellite. 

The  transfer  of  the  VLR  database  has  advantages  and  disadvantages.  The  first 
advantage  is  that  an  up-to-date  database  limits  the  number  of  times  the  HLR  needs  to  be 
accessed.  All  authentication  and  location  update  is  done  locally  with  only  one 
registration  message  needed  sent  to  the  HLR  every  9  minutes.  The  disadvantage  is  the 
amount  of  information  needed  to  be  transferred  between  satellites. 

The  three  test  cases  weigh  the  advantages  and  disadvantages  of  database  transfer. 
During  a  light  load,  when  there  are  few  subscribers  on  the  air,  the  database  transfer 
should  be  an  advantage.  During  a  heavy  load,  the  database  becomes  much  larger  and  the 
advantage  of  an  up-to-date  database  may  be  overcome  by  the  cost  of  transferring  large 
amounts  of  the  data. 

4.7.  Satellite  VLR  Periodic  Updates 

The  fifth  and  final  scenario  makes  the  most  changes  to  the  protocol  provided  by  IS- 
41-C.  Once  again  the  VLR  and  AC  are  located  in  the  satellite,  but  now  the  VLR  database 
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is  not  transferred  from  one  satellite  to  another.  Instead  the  database  is  rebuilt  every  time 
a  new  satellite  comes  into  view.  The  difference  between  this  scenario  and  the  second 
one,  is  that  the  HLR  is  not  informed  about  the  changes,  unless  the  MS  indicates  it  has 
traveled  into  a  new  location  area. 

By  eliminating  constant  location  updating  of  the  HLR  database,  when  the  only 
change  is  the  satellite  supporting  the  MS,  the  number  of  messages  should  finally  be 
reduced  to  an  equivalent  amount  as  the  first  scenario.  The  chief  advantage  of  this 
scenario  is  the  localization  of  the  VLR  without  the  penalty  of  database  transfer. 

The  expected  results  is  a  reduction  in  both  the  number  of  hops  required  to  complete  a 
mobility  management  conversation  and  a  reduction  in  the  number  of  conversation  needed 
to  maintain  the  location  of  the  mobile  subscribers. 

4.8.  Analysis  of  Performance  Metrics 

The  primary  measurements  used  to  assess  the  overhead  involved  in  performing  the 
mobility  management  functions  in  the  Iridium®  are  the  average  number  of  hops  per 
message,  total  number  of  conversations,  total  number  of  hops,  and  total  number  of  bytes 
passed  in  support  of  mobility  management.  These  metrics  are  defined  in  Section  3.10. 

Each  of  the  measurements  is  collected  as  described  in  Section  4.3,  with  every 
scenario  executed  five  times,  with  each  run  having  a  different  seed.  The  particular 
performance  metric  data  is  then  averaged  and  a  standard  deviation  is  calculated.  From 
this,  a  95  percent  confidence  level  is  derived.  All  the  charts  in  this  chapter  have  been 
designed  to  clearly  show  the  confidence  levels.  Using  a  floating  bar  chart,  the  values 
from  each  of  the  five  scenarios  are  stacked.  The  value  is  displayed  as  a  bar,  with  the 
length  of  the  bar  show  the  confidence  level  of  the  data.  Any  overlapping  bars  indicate 
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that  the  values  in  question  are  not  statistically  different  and  should  be  considered  as 
equivalent. 

4.8.1.  Analysis  of  the  Average  Number  of  Hops 

The  first  metric  collected  and  analyzed  is  the  average  number  of  hops  a  message  takes 
from  one  mobility  management  entity  to  another.  The  lower  the  number  of  hops,  the 
quicker  the  message  arrives  at  its  destination,  and  the  lower  the  bandwidth  utilization 
required  for  the  message. 

According  to  Lee,  the  number  of  hops  required  for  a  Gateway  Approach  algorithm  is 
expected  to  require  at  least  two  more  hops  than  using  a  Satellite  Approach  [Lee97].  The 
research  in  this  thesis  verifies  his  conclusion.  When  the  VLR  resided  in  the  terrestrial 
gateway,  it  took  7.07  hops  (low  load  scenario)  to  send  a  message  from  one  mobility 
management  function  to  another.  Once  the  VLR  is  moved  to  satellite,  the  hop  count 
dropped  to  4.01  (low  load  scenario).  Figures  14-16  show  that  moving  the  VLR  closer  to 
the  mobile  subscriber  eliminated  one  uplink  and  downlink  required  to  access  the 
earthbound  VLR.  The  other  hop  eliminated  occurred  due  to  the  internal  structure  of  the 
terrestrial  gateway.  In  the  standard  model,  the  VLR,  AC,  and  HLR  are  all  located 
together  in  the  terrestrial  gateway,  and  have  internal  connections  to  pass  messages  to  each 
other.  So  certain  mobility  management  messages  are  sent  internally  and  are  not  reflected 
in  the  average  hop  count.  This  eliminates  many  single  hop  messages,  increasing  the  hop 
count  average  for  the  messages  that  are  sent  over  the  network. 

The  average  number  of  hops  also  decreased  by  one  when  the  Authentication  Center  is 
placed  in  the  satellites.  In  the  low  load  scenario,  the  hop  count  is  reduced  from  4.01  to 
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2.98.  Again,  moving  a  mobility  management  function  closer  to  the  user  decreased  the 
number  of  hops  needed  to  communicate  with  that  entity. 

The  other  important  inference  derived  from  this  metric  is  that  the  method  to  update 
the  VLR  had  very  little  effect  on  the  average  number  of  hops.  The  database  transfer 
scenario  showed  a  slightly  lower  hop  count,  because  of  the  addition  of  the  single  hop 
database  transfer  conversation. 


Hop  Count 


Figure  17.  Average  Number  of  Hops  (Low  Load) 


Figure  18.  Average  Number  of  Hops  (High  Load) 
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Figure  19.  Average  Number  of  Hops  (Modified  Load) 

4.8.2.  Analysis  of  Number  of  Conversations 

A  conversation  is  defined  as  a  series  of  messages  required  to  complete  a  single 
management  task.  Management  tasks  include  updating  the  location  of  a  mobile 
subscriber  or  establishing  a  call  between  two  customers.  The  number  of  conversations 
made  during  a  simulation  run  is  the  combination  of  three  factors:  a  random  seed 
generating  the  calls,  a  random  seed  determining  the  next  action  of  a  mobile  subscriber, 
and  the  number  of  mandatory  location  update.  The  lower  number  of  conversations,  the 
less  traffic  that  needs  to  be  generated. 

At  a  low  load,  the  number  of  conversations  is  generally  low,  and  all  the  algorithms 
generated  approximately  the  same  amount  of  traffic.  Figure  20  shows  that  the  difference 
between  the  high  value  of  2223.8  and  the  low  value  of  1662  is  only  about  25.3  percent. 
Statistically,  the  topologies  fell  into  two  groups:  the  standard  IS-41-C  and  the  VLR 
location  update  in  one,  and  the  other  three  topologies  in  the  other.  The  first  group 
generated  approximately  1675  conversations,  while  the  other  three  topologies  generated 
about  2200  conversations.  The  key  difference  is  the  number  of  location  update  messages 


106 


generated  independent  of  the  load.  A  more  in-depth  look  at  location  update 
conversations  is  discussed  in  the  next  subsection. 

The  two  groupings  seen  in  the  low  load  test  case,  were  also  seen  in  the  high  load  test, 
as  shown  in  Figure  21.  The  groupings  are  even  more  pronounced  in  the  modified  load 
test  case  (Figure  22).  Overall  the  number  of  conversations  generated  favored  the 
topologies  that  limited  the  number  of  location  update  messages  required  to  be  sent. 


Figure  20.  Number  of  Conversations  (Low  Load) 


Figure  21.  Number  of  Conversations  (High  Load) 


107 


Figure  22.  Number  of  Conversations  (Modified  Load) 


4.8.2. 1  Analysis  of  Location  Update  Conversations 

A  preliminary  analysis  of  the  number  of  conversations  generated  by  each  of  the 
topologies  seemed  to  favor  the  protocols  with  the  fewest  location  updates.  To  verify  this 
hypothesis,  the  number  of  location  update  messages  is  examined  more  closely.  In  Figure 
23,  the  low  load  test  case  supports  the  conclusion  that  number  of  location  updates  directly 
affected  the  total  number  of  conversations  by  each  of  the  scenarios.  A  quick  check  shows 
that  the  difference  in  total  conversations  between  the  IS-41-C  and  the  VLR  on  the 
satellite  scenarios,  in  the  low  load  test  case,  is  561.8.  The  difference  in  location  update 
conversations  between  the  same  two  scenarios  is  452.4.  So  80.5  percent  of  the  difference 
is  due  to  location  update  message. 

An  analysis  of  the  high  load  (Figure  24)  and  the  modified  load  (Figure  25)  revealed 
the  same  pattern  evident  in  the  low  load  test  case.  The  gap  between  the  two  groups 
increased  in  the  modified  load  test  cases  to  3111.4,  from  the  standard  protocol's  3788.2 
conversation  to  VLR  in  the  Satellites'  6899.6.  The  increase  is  due  to  the  modified  load's 
change  in  the  periodic  update  to  once  every  20  minutes,  if  not  done  earlier.  The  standard 
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and  discard  VLR  database  scenarios  are  able  to  take  advantage  of  the  longer  update 
interval  and  reduced  number  of  updates.  The  other  three  scenarios  could  not,  because 
they  updated  location  of  the  mobile  subscribers  during  every  handover. 


Location  Update  Messages  by  Scheme 


Figure  23.  Location  Updates  (Low  Load) 


Figure  24.  Location  Updates  (High  Load) 
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Figure  25.  Location  Updates  (Modified  Load) 


4.8.3.  Analysis  of  Calls  Lost 

Calls  are  considered  lost  when  one  of  three  conditions  exists.  First,  the  MS  has  never 
reported  in  and  the  HLR  has  the  user  marked  as  unknown.  The  second  condition  occurs 
when  the  MSC  pages  the  last  known  location  of  the  MS  and  the  MS  is  not  found. 
Finally,  the  HLR  routes  a  message  request  to  a  VLR  that  doesn't  have  knowledge  of  the 
MS  addressed  in  the  message.  Lost  messages  signify  the  inability  to  reach  the  user  due  to 
a  problem  in  the  mobility  management  scheme. 

With  the  mobile  subscriber  group  being  stationary,  the  number  of  lost  calls  should  be 
zero.  Unfortunately,  that  goal  is  not  met.  Analysis  of  the  individual  records  reveal  the 
majority  of  the  lost  calls  occur  because  some  mobile  subscribers  never  check-in.  This 
explains  why  the  number  of  lost  calls  is  roughly  equivalent  in  the  low  load  (Figure  26) 
and  high  load  (Figure  27)  test  cases.  Once  a  majority  of  the  subscribers  register,  the 
number  of  lost  calls  decreases  dramatically.  The  modified  load  (Figure  28),  and  the  low 
load  scenarios  show  a  clear  separation  between  the  standard  and  VLR  location  update 
scenarios.  The  possible  reason  for  this  separation  is  the  method  of  location  update  for 
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two  is  different.  With  the  standard  protocol,  each  registration  is  reported  to  the  HLR, 
while  in  the  location  update  scenario,  only  selected  updates  are  reported.  The  database 
discard  scenario  in  all  cases  is  more  than  any  of  the  other  scenarios.  This  is  due  to  the 
limited  interaction  between  the  VLR  and  HLR. 

IS-41-C 

VLR  on  Sat 

AC  on  Sat 

D  atabase 

Tran  sfer 

DB  Discard 

3  6  8  11  13 

Calis  Lost  by  Scheme 

Figure  26.  Number  of  Calls  Lost  (Low  Load) 


Figure  27.  Number  of  Call  Lost  (High  Load) 
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VLR  on  Sat 

AC  on  Sat 

D  atabase 
Transfer 

DB  Discard 

10  20  30  40 

Calls  Lost  by  Scheme 

Figure  28.  Number  of  Lost  Calls  (Modified  Load) 

4.8.4.  Analysis  of  Total  Hop  Count 

The  total  number  of  hops  is  the  combination  of  messages  sent  and  the  number  of  hops 
each  message  took  to  reach  the  destination.  This  shows  one  measure  of  the  efficiency  of 
the  protocol  examined.  The  fewer  the  number  of  hops  taken,  the  less  time  and  bandwidth 
is  needed  by  the  mobility  management  to  perform  its  task. 

Examining  the  charts  for  the  low  load  (Figure  29),  high  load  (Figure  30)  and  modified 
load  (Figure  31)  test  cases,  a  clear  delineation  occurs  once  the  Authentication  Center  is 
moved.  Authentication  makes  a  difference,  because  each  mobility  management  activity 
requires  authentication  at  some  point  in  the  process.  With  at  least  a  two  hop  distance 
between  the  MS  Group  and  the  nearest  terrestrial  gateway,  having  to  get  the  Secret 
Shared  Data  adds  at  least  four  hops  to  each  conversation. 
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Figure  29.  Total  Hops  (Low  Load) 


Figure  30.  Total  Hops  (High  Load) 


Figure  31.  Total  Hops  (Modified  Load) 
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4.8.5.  Analysis  of  Total  Management  Messages  Sent 

Another  measurement  of  the  efficiency  of  a  mobility  management  scheme  is  the 
number  of  messages  that  need  to  be  sent  to  perform  its  required  tasks.  The  number  of 
messages  includes  only  those  messages  that  must  be  passed  from  one  node,  gateway,  MS 
group,  or  satellite,  to  another.  Internal  node  traffic  is  not  considered  because  it  doesn't 
use  satellite  bandwidth.  The  fewer  number  of  messages  needed  to  complete  a  task  the 
better. 

In  this  measurement,  the  standard  IS-41-C  sends  the  fewest  number  of  messages  over 
the  airwaves.  In  the  high  load  test  case  (Figure  33),  the  standard  protocol  only  sent  7261 
messages,  while  the  next  best  scheme,  the  VLR  database  discard  protocol  sent  9,982 
messages,  an  increase  of  2721.  The  low  count  on  the  standard  protocol  can  be  attributed 
to  the  collocation  of  all  the  major  mobility  management  components.  Since  only  six 
gateways  are  modeled,  and  the  assignment  of  mobile  subscribers  to  HLRs  is  evenly 
distributed,  in  one  out  of  every  six  conversations  the  mobile  subscriber's  VLR  and  HLR 
are  located  in  the  same  gateway.  This  increased  the  number  of  messages  kept  in  the 
gateway,  and  reduced  network  traffic.  The  VLR  location  update  scenario  did  well 
because  the  algorithm  is  specifically  designed  to  reduced  the  number  of  messages  sent 
over  the  ISLs.  Only  one  message  is  sent  out  during  the  first  location  update  of  a 
subscriber,  and  none  after  that.  The  other  scenarios  partition  the  mobility  management 
functions  into  two  geographically  separated  locations  and  this  requires  additional 
messages  to  be  passed  to  complete  a  mobility  management  task.  This  pattern  was 
repeated  in  the  low  load  (Figure  32)  and  model  load  (Figure  34)  scenarios. 
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Figure  32.  Total  Management  Messages  Sent  (Low  Load) 
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Figure  33.  Total  Management  Messages  Sent  (High  Load) 
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Figure  34.  Total  Management  Messages  Sent  (Modified  Load) 
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4.8.6.  Analysis  of  Total  Management  Bytes  Sent 

The  final  metric  examined  is  the  total  number  of  management  bytes  that  are  sent  by 
each  scenario  during  the  1,704  second  simulation  execution.  The  number  is  generated  by 
summing  the  network  load  for  every  message  that  is  passed.  The  network  load  is  defined 
as  the  size  of  a  management  message  multiplied  by  the  number  of  hops  required  for  the 
message  to  get  from  the  source  to  destination.  The  total  number  of  bytes  shows  the  load 
offered  to  the  network  to  perform  mobility  management  tasks.  This  reflects  to  overhead 
associated  with  the  protocol  and  must  be  subtracted  from  the  total  bandwidth  to  get  the 
bandwidth  available  to  the  user. 

The  first  conclusion  derived  from  the  metric  is  that  by  moving  the  VLR  from  the 
gateway  and  into  the  satellite,  the  traffic  load  on  the  network  is  increased.  The  largest 
differential  occurred  in  the  modified  load  test  case  (Figure  37).  The  standard  protocol 
generated  2,277,900  bytes  of  traffic,  while  after  moving  the  VLR,  mobility  management 
traffic  increased  to  3,390,300  bytes.  This  corresponds  to  an  33  percent  increase  in  the 
load.  The  large  difference  can  be  explained  by  two  factors.  First,  the  messages  that 
formerly  are  sent  internally  between  the  HLR  and  VLR  are  now  required  to  be  sent  over 
the  network.  Second,  when  a  mobile  subscriber  contacts  a  new  satellite,  the  VLR  on¬ 
board  has  no  prior  knowledge  of  the  subscriber  and  must  complete  the  initial  registration, 
instead  of  the  abbreviated  conversation  used  for  subsequent  location  updates. 

Another  conclusion  is  that  transferring  the  database  between  the  satellites  doesn't 
measurably  decrease  that  traffic  load.  In  the  high  load  test  case  (Figure  36),  the  AC  in 
the  satellite  scenario  produced  2,516,400  bytes  while  the  database  transfer  scenario 
produced  2,525,300  bytes.  The  difference  is  statistically  insignificant.  In  the  data 
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transfer  scheme,  the  advantage  of  a  reduction  in  location  management  costs  is  offset  by 
the  cost  of  moving  the  database  from  one  satellite  to  another.  Once  again,  the  low  load 
scenario  (Figure  35)  displayed  the  same  pattern. 


Figure  35.  Total  Management  Bytes  Sent  (Low  Load) 


Figure  36.  Total  Management  Bytes  Sent  (High  Load) 
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Figure  37.  Total  Management  Bytes  Sent  (Modified  Load) 


4.9.  Analysis  of  the  Mobility  Management  Overhead 

To  this  point,  the  analysis  has  been  a  comparison  of  mobility  management  traffic 

characteristics  of  the  five  scenarios  tested.  This  section  relates  the  mobility  management 
overhead  on  the  network.  Overhead  is  the  total  number  of  packets  introduced  into  the 
network  to  complete  the  required  mobility  management  tasks.  Overhead  is  calculated  by 
dividing  the  total  network  traffic  into  the  total  number  of  mobility  management  packets 
generated  in  each  scenario.  In  general,  lower  overhead  indicates  better  performance. 

As  mentioned  earlier,  the  maximum  packet  arrival  rate  for  a  satellite  is  21,333 
packets  per  second.  With  66  satellites  in  the  Iridium®  system,  the  network  can  support  a 
maximum  of  1,407,978  packets  per  second.  Each  packets  is  216  bits  or  27  bytes  in  size. 
Mobility  management  messages  range  in  size  from  12  to  105  bytes,  so  only  between  one 
and  four  data  packets  are  required  to  send  a  message.  Re-examining  the  high  load 
scenarios,  the  number  of  packets  is  determined.  The  results  are  presented  in  Table  7. 
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Table  7.  Total  Number  of  Packets  Sent  (Low  Load) 


Scenario 

Total  Packets  (scaled) 

Total  Packets 

Overhead 

IC-41-C 

88,346.84 

447.82 

2.32% 

VLR  on  Satellite 

106,506.10 

520.86 

2.44% 

AC  on  Satellite 

77,005.05 

376.59 

1.77% 

Database  Transfer 

77,115.88 

377.13 

1.77%  j 

63,852.56 

312.27 

1.46% 

The  numbers  are  for  the  scaled  model  of  the  true  system,  so  the  true  number  of 
packets  introduced  into  the  system  is  25  times  greater.  Column  three  in  Table  7 
represents  the  actual  traffic  load  per  satellite  per  second.  Recalling  Fossa  work,  a  satellite 
can  handle  21,333  packets  per  second.  Overhead  is  calculated  by  dividing  the  total 
network  traffic  into  the  total  number  of  mobility  management  packets  generated  in  each 
scenario.  These  number  reflect  that  even  at  a  low  load  between  1.46  and  2.44  percent  of 
the  bandwidth  is  used  by  mobility  management  traffic. 

4.10.  Summary  of  Analysis 

In  this  chapter,  an  analysis  of  the  mobility  management  traffic  characteristics  for  five 
different  Iridium®  scenarios  are  presented.  The  overall  analysis  shows  that  moving  the 
VLR  to  the  satellite  without  making  modifications  to  the  mobility  management  protocol 
causes  the  communication  overhead  to  increase  approximately  33  percent.  If 
modifications  are  made  to  the  protocol,  then  a  bandwidth  savings  can  be  achieved. 

The  overhead  associated  the  mobility  management  is  found  to  be  approximately  1.46 
to  2.44  percent.  When  this  overhead  is  added  to  the  overhead  created  by  a  routing 
algorithm,  for  example,  Darting  (3.3  percent  to  3.8  percent)  [Pra99],  then  up  to  4.04 
percent  of  the  total  available  bandwidth  is  occupied.  This  translates  to  Iridium®  having  to 
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drop  support  to  3,474  active  customers,  or  only  support  82,525  mobile  users  instead  of 
86,000  advertised.  By  improving  the  efficiency  of  mobility  management  algorithm, 
enough  bandwidth  can  be  saved  to  support  an  additional  860  users. 


120 


Chapter  5:  Conclusions  and  Recommendations 


For  every  complex  problem,  there  is  a  solution  that  is  simple,  neat,  and  wrong. 

-  H.  L.  Mencken  (1880  -  1956) 

5.1.  Restatement  of  Research  Goal 

This  research  had  two  goals: 

•  to  compare  the  overhead  associated  with  different  mobility  management  schemes 

•  to  determine  if  a  topology,  taking  in  account  the  strengths  and  weaknesses  of  LEO 
satellites,  has  less  overhead  than  a  standard  terrestrial-based  topology. 

5.2.  Conclusions 

5.2.1.  Results  Synopsis 

Five  scenarios  were  developed  to  compare  two  aspects  of  mobility  management 
protocols.  The  first  aspect  is  the  location  of  mobility  management  function.  Specifically, 
this  thesis  examined  the  change  in  overhead  associated  with  mobility  management  by 
changing  the  placement  of  the  Visitor  Location  Register  (VLR)  and  Authentication 
Center  (AC)  from  the  terrestrial  gateways  to  the  satellite  As  a  follow  on,  it  compared 
three  methods  of  updating  the  VLR,  when  the  VLR  is  located  in  the  satellite.  Three 
different  update  schemes  were  examined  including  the  standard  IS-41-C  protocol, 
transferring  the  database  from  one  satellite  to  another,  or  discarding  the  database  and 
rebuilding  it  from  scratch. 

The  thesis  results  show  that  simply  moving  the  VLR  from  the  gateway  to  the  satellite 
did  not  decrease  the  traffic  overhead  associated  with  mobility  management.  In  fact,  the 
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amount  of  traffic  increased  about  33  percent.  Moving  both  the  AC  and  VLR  together  to 
the  satellite  did  decrease  the  traffic  load  by  an  average  of  10  percent. 

With  the  AC  and  VLR  moved  to  the  satellite,  it  is  determined  that  with  certain 
changes  to  the  protocol,  completely  discarding  the  database  and  rebuilding  it  from  scratch 
is  the  best.  The  standard  protocol  requires  the  VLR  to  update  the  subscriber's  VLR  entry 
in  the  HLR  database  after  each  satellite  hand-over,  regardless  of  whether  the  subscriber 
moved  or  not.  The  HLR  is  then  required  to  deregister  the  subscriber  from  the  satellite 
last  handling  the  subscriber.  Both  actions  added  needless  messages  to  the  network.  The 
second  update  scheme  transferred  the  VLR  database  from  satellite  currently  handling  the 
mobile  subscribers  to  the  satellite  handling  the  subscribers  next.  This  did  not  decrease 
the  traffic  overhead  because  the  savings  in  traffic  load  were  offset  by  the  amount  of  data 
moved  from  one  satellite  to  the  next. 

The  final  update  scheme  discarded  the  database  and  rebuilt  it  from  scratch.  This 
scheme  reduced  the  mobility  management  traffic  by  30  percent  by  taking  advantage  of 
the  properties  of  the  satellite  constellation.  The  first  property  used  is  that  satellites  cannot 
cover  the  same  geographic  location  longer  than  9  minutes  and  8  seconds.  If  a  subscriber 
has  not  updated  its  location  within  that  time,  it  is  no  longer  in  the  satellite's  footprint,  and 
it's  VLR  entry  is  purged.  This  means  that  the  HLR  never  needs  to  send  a  deregistration 
message.  The  LEO  satellites  have  steerable  antennas  and  so  the  Earth  can  be  divided  into 
2150  cells.  The  location  of  each  cell  is  associated  with  a  fixed  geographic  location  and  is 
given  a  unique  identifier.  While  a  cell  is  in- view  of  a  satellite,  the  satellite  maintains  the 
same  beam  on  the  cell  and  broadcasts  the  cell's  identifier.  This  identifier  is  the  VLR 
location  address  stored  in  the  HLR.  This  scheme  reduces  the  number  of  registration 
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messages  sent  to  HLR.  Only  when  the  subscriber  enters  a  new  cell  is  the  HLR  updated. 
With  the  AC  and  VLR  collocated  on  the  satellite,  the  satellite  can  interrogate  suspect 
mobile  subscribers  without  HLR  intervention.  This  reduces  authentication  traffic. 
Finally,  the  HLR  has  knowledge  of  what  satellite  is  covering  a  particular  cell  at  a 
particular  time,  so  it  can  send  messages  without  prior  knowledge  by  the  VLR.  If  the 
VLR  receives  a  connection  request  before  it  has  established  the  subscriber's  presence,  it 
will  try  to  process  the  request  anyway.  These  properties  allowed  the  total  mobility  traffic 
overhead  to  be  reduced  by  30  percent. 

5.2.2.  Recommendations 

If  the  conservation  of  Inter-Satellite  Link  (ISL)  bandwidth  is  important,  then  moving 
the  VLR  and  AC  to  the  satellite  is  recommended,  provided  the  proper  changes  to  the 
mobility  management  protocol  are  made.  The  changes  recommended  are  outlined  in  the 
preceding  paragraph.  The  most  significant  benefit  of  the  proposed  changes  is  that  they 
are  internal  to  the  Iridium®  system  and  does  not  effect  the  Iridium®'s  interoperability  with 
any  terrestrial  system  using  IS-41-C. 

The  satellite  hardware  needs  to  be  upgraded.  The  satellite  needs  approximately 
205,920  bytes  of  memory  to  store  the  VLR  database,  and  an  additional  120  MB  of 
memory  for  the  AC  database.  The  on  board  processor  needs  to  handle  all  VLR  and  AC 
functions,  especially  VLR  table  lookups  and  authentication  generation  quickly,  in  less 
than  1  second. 
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5.3.  Significant  Results  of  Research 

This  work  is  the  first  to  examine  traffic  overhead  in  a  Low  Earth  Orbiting  (LEO) 
satellite  at  the  protocol  level.  All  previous  research  concentrated  on  comparison  studies 
at  the  data-link  and  network  routing  layer.  This  work,  by  combining  the  aspects  of 
mobility  management  protocols  with  the  dynamic  nature  of  a  LEO  constellation,  is  able 
to  obtain  results  that  are  overlooked  when  the  factors  are  considered  separately. 

5.4.  Future  Research 

This  research  can  be  expanded  in  three  major  areas.  First,  the  only  protocol  tested 
was  IS-41-C.  This  is  the  standard  protocol  for  North  America,  and  the  Iridium®  satellite, 
but  other  protocols  are  in  use  throughout  the  world.  The  most  significant  is  Global 
System  for  Mobile  Communication  (GSM),  and  its  corresponding  over-the-air  protocol 
called  Mobile  Application  Part  (MAP).  This  is  a  more  complex  protocol  and  requires  a 
different  message  passing  sequence  to  complete  mobility  management  tasks.  So  results 
using  GSM  MAP  would  likely  lead  to  conclusions  different  from  those  presented  in  this 
thesis.  Testing  GSM  MAP  is  important,  since  the  next  generation  of  communication 
satellites  will  probably  use  a  version  of  GSM,  instead  of  IS-41-C. 

The  second  area  of  research  is  modeling  the  spot-beams  of  the  Iridium®  satellite.  By 
simplifying  the  model  to  exclude  spot-beams,  it  was  not  possible  to  test  some  of  the 
newer  paging  schemes  suggested  in  various  publications  [AkH95a,  AkH95b,  GuR98]. 
Chapter  2  discusses  of  the  paging  schemes  that  have  been  recommended  in  the  available 
literature.  Reducing  the  amount  of  paging  traffic  can  increase  the  available  bandwidth 
for  the  mobile  subscribers. 
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Another  area  of  research  is  moving  the  Home  Location  Register  into  the  satellite,  or 
into  geostationary  satellites,  which  communicate  with  the  LEOs.  This  area  was  not 
pursued  because  of  it  seemed  unlikely  to  reduce  the  overhead  involved.  But,  as  this 
thesis  has  shown,  with  proper  modifications  to  the  protocol,  it  may  result  in  a  reduction  in 
overhead. 

The  final  area  of  research  would  involve  modifying  the  protocol  at  a  message  level. 
Most  mobility  management  protocols  are  designed  to  work  in  a  heterogeneous 
environment.  This  requires  an  additional  layer  of  complexity,  and  causes  additional 
fields  to  be  added  to  the  messages.  This  aspect  would  not  be  required  in  a  homogenous 
environment  such  as  the  Iridium®  network. 
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Appendix 

This  appendix  contains  the  tabulated  results  from  a  selected  number  of  statistics 
gathered  during  the  75  simulation  runs  and  the  90%  confidence  intervals  for  each  test 
scenario. 


Table  8.  Number  of  Conversations  Generated  (Low  Load) 


Scheme 

seed 

seed 

seed 

seed 

seed 

Mean 

Standard 

90%  Confidence  | 

128 

222 

007 

397 

428 

Deviation 

Min 

Max 

IC-41-C 

1696 

1700 

1637 

1666 

1611 

1662 

38.21649 

1633.89 

1690.11 

VLR  on  Sat 

2274 

2280 

2214 

2176 

2175 

2223.8 

51.09012 

2186.22 

2261.38 

AC  on  Sat 

2136 

2318 

2183 

2149 

2250 

2207.2 

76.07693 

2151.24 

2263.16 

DB  Transfer 

2211 

2258 

2204 

2077 

2167 

2183.4 

67.71484 

2133.60 

2233.21 

DB  Discard 

1722 

1669 

1704 

1682 

1709 

1697.2 

21.37054 

1681.48 

1712.92 

Table  9.  Number  of  Conversations  Generated  (High  Load) 


Scheme 

seed 

seed 

seed 

seed 

seed 

Mean 

Standard 

90%  Confidence 

128 

222 

007 

397 

428 

Deviation 

Min 

Max 

IC-41-C 

2889 

2921 

2816 

2777 

2810 

2842.6 

59.944 

2798.50 

2886.70 

VLR  on  Sat 

4026 

4007 

3980 

3801 

4016 

3966.0 

93.8110 

3896.99 

4035.00 

AC  on  Sat 

4071 

4063 

3868 

3912 

3950 

3972.8 

90.8003 

3906.00 

4039.59" 

DB  Transfer 

4012 

4157 

3938 

3947 

3867 

3984.2 

109.4153 

3903.71 

4064.68 

DB  Discard 

3032 

3018 

3008 

2885 

2892 

2967.0 

72.2080" 

2913.88 

3020.11 

Table 

10.  N 

umber  of  Conversations  Generated  (Mi 

edified  Load) 

Scheme 

seed 

seed 

seed 

seed 

seed 

Mean 

Standard 

90%  Confidence 

128 

222 

007 

397 

428 

Deviation 

Min 

Max 

IC-41-C 

3947 

4019 

3682 

3612 

3681 

3788.2 

181.867 

3654.42 

3921.98 

VLR  on  Sat 

6781 

6900 

6976 

6834 

7007 

6899.6 

94.527 

6830.07 

6969.13 

AC  on  Sat 

6795 

6774 

6708 

6851 

7070 

6839.6 

138.588 

6737.66 

6941.55 

DB  Transfer 

6860 

6840 

6908 

6712 

6724 

6808.8 

86.598 

6745.10 

6872.50 

DB  Discard 

3994 

4071 

3943 

3926 

3965 

3979.8 

56.980 

3937.89 

4021.71 

126 


Table  11.  Number  of  Location  Update  Conversations  (Low  Load) 


Scheme 

seed 

seed 

seed 

seed 

seed 

Mean 

Standard 

90%  Confidence  | 

128 

222 

007 

397 

428 

Deviation 

Min 

Max 

IC-41-C 

780 

782 

778 

782 

777 

779.8 

2.280 

778.12 

781.48 

VLR  on  Sat 

1262 

1244 

1201 

1233 

1221 

1232.2 

23.059 

1215.24 

1249.16 

AC  on  Sat 

1181 

1281 

1205 

1173 

1251 

1218.2 

46.424 

1184.05 

1252.35 

DB  Transfer 

1217 

1244 

1190 

1166 

1171 

1197.6 

32.761 

1173.50 

1221.70 

DB  Discard 

776 

775 

769 

775 

768 

772.6 

3.782 

769.82 

775.38 

Table  12.  Number  of  Location  Update  Conversations  (High  Load) 


Scheme 

seed 

seed 

seed 

seed 

seed 

Mean 

Standard 

90%  Confidence  | 

128 

222 

007 

397 

428 

Deviation 

Min 

Max 

IC-41-C 

1557 

1573 

1556 

1560 

1568 

1562.8 

7.396 

1557.36 

1568.24 

VLR  on  Sat 

2431 

2389 

2416 

2360 

2431 

2405.4 

30.632" 

2382.87 

2427.93 

AC  on  Sat 

2491 

2480 

2348 

2389 

2411 

2423.8 

60.817 

2379.06 

2468.54 

DB  Transfer 

2430 

2490 

2365 

2456 

2368 

2421.8 

54.792" 

2381.50 

2462.11 

DB  Discard 

1550 

1538 

1545 

1555 

1543 

1546.2 

6.535 

1541.40 

1551.01 

Table  13.  Number  of  Location  Update  Conversations  (Modified  Load) 


Scheme 

seed 

seed 

seed 

seed 

seed 

Mean 

Standard 

90%  Confidence  | 

128 

222 

007 

397 

428 

Deviation 

Min 

Max 

IC-41-C 

1603 

1587 

1185 

1200 

1191 

1353.2 

220.869 

1190.73 

1515.67 

VLR  on  Sat 

2593 

2593 

2607 

2568 

2633 

2598.8 

23.732 

2581.34 

2616.26 

AC  on  Sat 

2590 

2549 

2552 

2589 

2622 

2580.4 

30.369 

2558.06 

2602.74 

DB  Transfer 

2628 

2604 

2571 

2561 

2576 

2588.0 

27.468 

2567.79 

2608.21 

DB  Discard 

1125 

1151 

1134 

1141 

1142 

1138.6 

9.711 

1131.46 

1145.74 

127 


Table  14.  Number  of  Deregistration  Conversations  (Low  Load) 


Scheme 

seed 

seed 

seed 

seed 

seed 

Mean 

Standard 

90%  Confidence  j 

128 

222 

007 

397 

428 

Deviation 

Min 

Max 

IC-41-C 

68 

68 

62 

64 

66 

65.6 

2.608 

63068 

67.52 

VLR  on  Sat 

94 

88 

83 

103 

78 

89.2 

9.731 

82.04 

96.36 

AC  on  Sat 

85 

96 

71 

85 

92 

85.8 

9.524 

78.79 

92.81 

DB  Transfer 

97 

83 

86 

92 

79 

87.4 

7.162 

82.13 

92.67 

DB  Discard 

51 

46 

54 

56 

49 

51.2 

3.962 

48.29 

54.11 

Table  15.  Number  of  Deregistration  Conversations  (High  Load) 


Scheme 

seed 

seed 

seed 

seed 

seed 

Mean 

Standard 

90%  Confidence 

128 

222 

007 

397 

428 

Deviation 

Min 

Max 

IC-41-C 

124 

146 

124 

123 

140 

131.4 

10.807 

123.45 

139.35 

VLR  on  Sat 

164 

176 

170 

160 

180 

170.0 

8.246 

163.93 

176.07 

AC  on  Sat 

154 

165 

160 

161 

186 

165.2 

12.276 

156.17 

174.23 

DB  Transfer 

168 

176 

157 

183 

166 

170.0 

9.925 

162.70 

177.30 

DB  Discard 

105 

91 

93 

111 

93 

98.6 

8.877 

92.07 

105.13 

Table  16.  Number  of  Deregistration  Conversations  (Modified  Load) 


Scheme 

seed 

seed 

seed 

seed 

seed 

Mean 

Standard 

90%  Confidence  | 

128 

222 

007 

397 

428 

Deviation 

Min 

Max 

IC-41-C 

732 

721 

247 

261 

250 

442.2 

259.611 

251.23 

633.17 

VLR  on  Sat 

509 

529 

546 

515 

523 

524.4 

14.276 

513.90 

534.90 

AC  on  Sat 

557 

510 

525 

530 

565 

537.4 

22.941 

520.52 

554.28 

DB  Transfer 

604 

550 

537 

502 

531 

544.8 

37.466 

517.24 

572.36 

DB  Discard 

165 

206 

179 

189 

190 

185.8 

15.123 

174.68 

196.92 

128 


Table  17.  Number  of  Calls  Attempted  (Low  Load) 


Scheme 

seed 

seed 

seed 

seed 

seed 

Mean 

Standard 

90%  Confidence  | 

128 

222 

007 

397 

428 

Deviation 

Min 

Max 

IC-41-C 

583 

570 

546 

568 

523 

558.0 

23.654 

540.60 

575.40 

VLR  on  Sat 

667 

660 

663 

606 

621 

643.4 

27.916 

622.87 

663.94 

AC  on  Sat 

638 

685 

645 

629 

659 

651.2 

21.845 

635.13 

667.27 

DB  Transfer 

651 

653 

667 

582 

640 

638.6 

33.065 

614.28 

662.92 

DB  Discard 

484 

450 

472 

450 

473 

465.8 

15.172 

454.64 

476.96 

Table  18.  Number  of  Calls  Attempted  (High  Load) 


Scheme 

seed 

seed 

seed 

seed 

seed 

Mean 

Standard 

90%  Confidence  | 

128 

222 

007 

397 

428 

Deviation 

Min 

Max  ; 

IC-41-C 

907 

863 

856 

821 

838 

857.0 

32.381 

833.18 

880.82 

VLR  on  Sat 

1079 

1073 

1078 

973 

1080 

1056.6 

46.811 

1022.17 

1091.03 

AC  on  Sat 

1104 

1095 

1048 

1056 

1056 

1071.8 

25.694 

1052.90 

1090.70 

DB  Transfer 

1075 

1151 

1081 

1019 

1029 

1071.6 

52.402 

1032.45 

1109.55 

DB  Discard 

727 

738 

739 

669 

694 

713.4 

30.794 

690.75 

736.05 

Table  19.  Number  of  Calls  Attempted  (Modified  Load) 


Scheme 

seed 

seed 

seed 

seed 

seed 

Mean 

Standard 

90%  Confidence  | 

128 

222 

007 

397 

428 

Deviation 

Min 

Max 

IC-41-C 

1150 

1202 

1662 

1639 

1681 

1466.8 

266.514 

1270.75 

1662.85 

VLR  on  Sat 

3046 

3121 

3169 

3135 

3182 

3130.6 

53.351 

3091.36 

3169.85 

AC  on  Sat 

3050 

3151 

3060 

3132 

3256 

3129.8 

83.098 

3068.67 

3190.93 

DB  Transfer 

3052 

3102 

3216 

3099 

3006 

3095.0 

78.224 

3037.46 

3152.54 

DB  Discard 

1384 

1384 

1353 

1343 

1344 

1361.6 

20.816 

1346.29 

1376.91 

129 


Table  20.  Number  of  Lost  Calls  (Low  Load) 


Scheme 

seed 

seed 

seed 

seed 

seed 

Mean 

Standard 

90%  Confidence  [ 

128 

222 

007 

397 

428 

Deviation 

Min 

Max 

IC-41-C 

5 

5 

2 

3 

4 

3.8 

1.304 

2.84 

4.76 

VLR  on  Sat 

8 

7 

4 

9 

6 

6.8 

1.924 

5.39 

8.21 

AC  on  Sat 

6 

6 

2 

6 

2 

4.4 

2.191 

2.79 

6.01 

DB  Transfer 

3 

6 

8 

5 

4 

5.2 

1.924 

3.79 

6.61 

DB  Discard 

7 

10 

14 

11 

5 

9.4 

3.507 

6.82 

1— 1 

00 

Table  21.  Number  of  Lost  Calls  (High  Load) 


Scheme 

seed 

seed 

seed 

seed 

seed 

Mean 

Standard 

90%  Confidence  | 

128 

222 

007 

397 

428 

Deviation 

Min 

Max 

IC-41-C 

5 

1 

7 

6 

4 

4.6 

2.302 

2.906 

6.29 

VLR  on  Sat 

10 

5 

10 

6 

12 

8.6 

2.966 

6.42 

10.78 

AC  on  Sat 

8 

9 

6 

5 

5 

6.6 

1.817 

5.26 

7.94 

DB  Transfer 

6 

9 

3 

7 

7 

6.4 

2.191 

4.79 

8.01 

DB  Discard 

12 

16 

20 

17 

14 

15.8 

3.033 

13.57 

18.03 

Table  22.  Number  of  Lost  Calls  (Modified  Load) 


Scheme 

seed 

seed 

seed 

seed 

seed 

Mean 

Standard 

90%  Confidence  | 

128 

222 

007 

397 

428 

Deviation 

Min 

Max 

IC-41-C 

34 

29 

10 

14 

9 

19.2 

11.520 

10.73 

27.67 

VLR  on  Sat 

32 

28 

23 

34 

18 

27.0 

6.557 

22.18 

31.82 

AC  on  Sat 

21 

28 

19 

17 

19 

20.8 

4.266 

17.66 

23.94 

DB  Transfer 

15 

15 

26 

20 

15 

18.2 

4.868 

14.62 

21.78 

DB  Discard 

29 

34 

27 

28 

33 

30.2 

3.114 

27.91 

32.49 
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Table  23.  Number  of  Hops  Taken  (Low  Load) 


Scheme 

seed 

seed 

seed 

seed 

seed 

Mean 

Standard 

90%  Confidence  j 

128 

222 

007 

397 

428 

Deviation 

Min 

Max  j 

IC-41-C 

16451 

16542 

15980 

16383 

16749 

16421.0 

282.42 

16213.2 

16628.8 

VLR  on  Sat 

19555 

21664 

19428 

18621 

20837 

20021.8 

1213.89 

19128.1 

20913.9 

AC  on  Sat 

13473 

15076 

14569 

13162 

13714 

13998.8 

797.39 

13412.2 

14585.4 

DB  Transfer 

13319 

15199 

14019 

13019 

14177 

13946.6 

848.70 

13322.3 

14570.9 

DB  Discard 

11798 

12204 

12239 

11632 

12190 

12012.6 

278.51 

11807.7 

12217.5 

Table  24.  Number  of  Hops  Taken  (High  Load) 


Scheme 

seed 

seed 

seed 

seed 

seed 

Mean 

Standard 

90%  Confidence  | 

128 

222 

007 

397 

428 

Deviation 

Min 

Max 

IC-41-C 

31466 

32241 

31614 

30789 

30708 

31363.6 

633.05 

30897.9 

31829.3 

VLR  on  Sat 

38423 

38281 

37415 

35060 

36625 

37160.8 

1379.59 

36146.0 

38175.6 

AC  on  Sat 

25008 

25805 

23937 

21980 

23503 

24046.6 

1465.83 

22968.3 

25124.9 

DB  Transfer 

24561 

25708 

24599 

23125 

22912 

24181.0 

1159.35 

23328.2 

25033.8 

DB  Discard 

21302 

21357 

21180 

13869 

19890 

19519.6 

3216.22 

17153.7 

21885.5 

Table  25.  Number  of  Hops  Taken  (Modified  Load) 


Scheme 

seed 

seed 

seed 

seed 

seed 

Mean 

Standard 

90%  Confidence  | 

128 

222 

007 

397 

428 

Deviation 

Min 

Max 

IC-41-C 

36183 

38297 

38261 

36131 

36248 

37024.0 

1146.47 

36180.7 

37867.4 

VLR  on  Sat 

54360 

54567 

54755 

54016 

54099 

54359.4 

310.37 

54131.1 

54587.7 

AC  on  Sat 

39899 

40660 

39034 

37303 

38493 

39077.8 

1291.47 

38127.8 

40027.8 

DB  Transfer 

38079 

40435 

39813 

39063 

38053 

39088.6 

1052.37 

38314.5 

39862.7 

DB  Discard 

28506 

29841 

28351 

26787 

28174 

28331.8 

1086.24 

27532.8 

29130.8 
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Table  26.  Millions  of  Mobility  Management  Octets  Sent  (Low  Load) 


Scheme 

seed 

seed 

seed 

seed 

seed 

Mean 

Standard 

90%  Confidence  | 

128 

222 

007 

397 

428 

Deviation 

Min 

Max 

IC-41-C 

1.008 

1.013 

.985 

1.007 

1.037 

1.0099 

0.0183 

0.9965 

1.0234 

VLR  on  Sat 

1.221 

1.347 

1.213 

1.151 

1.295 

1.2453 

0.0764 

1.1891 

1.3015 

AC  on  Sat 

0.873 

0.973 

0.927 

0.850 

0.891 

0.9029 

0.0482 

0.8674 

0.9383 

DB  Transfer 

0.871 

0.981 

0.905 

0.849 

0.913 

0.9037 

0.0503 

0.8667 

0.9407 

DB  Discard 

0.751 

0.780 

0.778 

0.738 

0.777 

0.7648 

0.0192" 

0.7507 

0.7790 

Table  27.  Millions  of  Mobility  Management  Octets  (High  Load) 


Scheme 

seed 

seed 

seed 

seed 

seed 

Mean 

Standard 

90%  Confidence  | 

128 

222 

007 

397 

428 

Deviation 

Min 

Max 

IC-41-C 

1.935 

1.982 

1.953 

1.896 

1.889 

1.9310 

0.0389 

1.9023 

1.9560 

VLR  on  Sat 

2.390 

2.390 

2.338 

2.205 

2.291 

2.3226 

0.0775 

2.2656 

2.3797 

AC  on  Sat 

1.655 

1.715 

1.602 

1.471 

1.550 

1.5984 

0.0938 

1.5294 

1.6674 

DB  Transfer 

1.629 

1.729 

1.638 

1.538 

1.528 

1.6124 

0.0825 

1.5517 

1.6730 

DB  Discard 

1.389 

1.388 

1.380 

1.305 

1.303 

1.3533 

0.0450 

1.3202 

1.3864 

Table  28.  Millions  of  Mobility  Management  Octets  (Modified  Load) 


Scheme 

seed 

seed 

seed 

seed 

seed 

Mean 

Standard 

90%  Confidence  j 

128 

222 

007 

397 

428 

Deviation 

Min 

Max 

IC-41-C 

7 

.211 

2 

.348 

2.358 

2.230 

2.242 

2.2779 

0.0699 

2.2265 

2.3293 

VLR  on  Sat 

1 

.383 

3 

.414 

3.423 

3.373 

3.359 

3.3903 

0.0274 

3.3702 

3.4105 

AC  on  Sat 

7 

.567 

7 

.614 

2.503 

2.406 

2.492 

2.5164 

0.0792 

2.4581 

2.5747 

DB  Transfer 

7 

.478 

7 

.597 

2.587 

2.520 

2.444 

2.5253 

0.0668 

2.4761 

2.5744 

DB  Discard 

7 

.772 

7 

.852 

1.765 

1.659 

1.743 

1.7583 

0.0690 

1.7076 

1.8090 
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Table  29.  Number  of  Mobility  Management  Packets  Sent  (Low  Load) 


Scheme 

seed 

seed 

seed 

seed 

seed 

Mean 

Standard 

90%  Confidence  | 

128 

222 

007 

397 

428 

Deviation 

Min 

Max 

IC-41-C 

3993 

4040 

3865 

3947 

3938 

3956.6 

65.401 

3908.49 

4004.71 

VLR  on  Sat 

7392 

7583 

7259 

7181 

7404 

7363.8 

153.996 

7250.52 

7477.08 

AC  on  Sat 

6807 

7399 

7127 

6714 

7000 

7009.4 

271.078 

6810.00 

7208.81 

DB  Transfer 

6831 

7273 

6966 

6646 

6899 

6923.0 

229.193 

6754.41 

7091.60 

DB  Discard 

5517 

5482 

5599 

5475 

5520 

5518.6 

49.268 

5482.36 

5554.84 

Table  30.  Number  of  Mobility  Management  Packets  Sent  (High  Load) 


Scheme 

seed 

seed 

seed 

seed 

seed 

Mean 

Standard 

90%  Confidence  | 

128 

222 

007 

397 

428 

Deviation 

Min 

Max 

IC-41-C 

7348 

7444 

7250 

7113 

7151 

7261.2 

137.097 

7140.3 

7362.0 

VLR  on  Sat 

13936 

13775 

13626 

13126 

13661 

13624.8 

303.940 

13401.2 

13848.4 

AC  on  Sat 

13052 

13082 

12304 

12066 

12657 

12632.2 

449.295 

12301.7 

12962.7 

DB  Transfer 

12820 

13059 

12668 

12597 

12291 

12687.0 

283.439 

12478.5 

12895.5 

DB  Discard 

10185 

10078 

10084 

9768 

9795 

9982.0 

188.145 

9843.6 

10120.4 

Table  31.  Number  of  Mobility  Management  Packets  Sent  (Modified  Load) 


Scheme 

seed 

seed 

seed 

seed 

seed 

Mean 

Standard 

90%  Confidence  | 

128 

222 

007 

397 

428 

Deviation 

Min 

Max 

IC-41-C 

9049 

9414 

8995 

8673 

8786 

8983.4 

285.118 

8773.7 

9193.1 

VLR  on  Sat 

21058 

21107 

21358 

21239 

21482 

21248.8 

175.296 

21119.9 

21377.8 

AC  on  Sat 

20121 

20295 

20145 

19770 

20344 

20135.0 

225.168 

19969.4 

20300.6 

DB  Transfer 

20006 

20442 

20161 

20220 

19850 

20135.8 

223.614 

19971.3 

20300.3 

DB  Discard 

12388 

12640 

12225 

12085 

12375 

12342.6 

207.211 

12190.2 

12495.0 
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